gball个人知识库
首页
基础组件
基础知识
算法&设计模式
  • 操作手册
  • 数据库
  • 极客时间
  • 每日随笔
  • 学习
  • 面试
  • 心情杂货
  • 实用技巧
  • 友情链接
  • 画图工具 (opens new window)
关于
  • 网盘 (opens new window)
  • 分类
  • 标签
  • 归档
项目
GitHub (opens new window)

ggball

后端界的小学生
首页
基础组件
基础知识
算法&设计模式
  • 操作手册
  • 数据库
  • 极客时间
  • 每日随笔
  • 学习
  • 面试
  • 心情杂货
  • 实用技巧
  • 友情链接
  • 画图工具 (opens new window)
关于
  • 网盘 (opens new window)
  • 分类
  • 标签
  • 归档
项目
GitHub (opens new window)
  • 面试

  • 数据库

  • linux

  • node

  • tensorFlow

  • 基础组件

  • 基础知识

  • 算法与设计模式

  • 分布式

  • 疑难杂症

  • go学习之旅

  • 极客时间

    • 设计模式之美

      • 开篇词 (1讲)

      • 设计模式学习导读 (3讲)

      • 设计原则与思想:面向对象 (11讲)

      • 设计原则与思想:设计原则 (12讲)

      • 设计原则与思想:规范与重构 (11讲)

        • 理论一:什么情况下要重构?到底重构什么?又该如何重构?
        • 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
        • 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
        • 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
        • 理论五:让你最快速地改善代码质量的20条编程规范(上)
        • 理论五:让你最快速地改善代码质量的20条编程规范(中)
          • 1.类、函数多大才合适?
          • 2.一行代码多长最合适?
          • 3.善用空行分割单元块
          • 4.四格缩进还是两格缩进?
          • 5.大括号是否要另起一行?
          • 6.类中成员的排列顺序
          • 重点回顾
          • 课堂讨论
          • 精选评论
        • 理论五:让你最快速地改善代码质量的20条编程规范(下)
        • 实战一(上):通过一段ID生成器代码,学习如何发现代码质量问题
        • 实战一(下):手把手带你将ID生成器代码从“能用”重构为“好用”
        • 实战二(上):程序出错该返回啥?NULL、异常、错误码、空对象?
        • 实战二(下):重构ID生成器项目中各函数的异常处理代码
      • 设计原则与思想:总结课 (3讲)

      • 设计模式与范式:创建型 (7讲)

      • 设计模式与范式:结构型 (8讲)

      • 设计模式与范式:行为型 (18讲)

      • 设计模式与范式:总结课 (2讲)

      • 开源与项目实战:开源实战 (14讲)

      • 开源与项目实战:项目实战 (9讲)

      • 开源与项目实战:总结课 (2讲)

      • 不定期加餐 (11讲)

      • 结束语 (1讲)

    • Redis核心技术与实战

理论五:让你最快速地改善代码质量的20条编程规范(中)

# 32 | 理论五:让你最快速地改善代码质量的20条编程规范(中)

上一节课中我们讲了命名和注释,这一节课我们来讲一下代码风格(CodeStyle)。说起代码风格,我们其实很难说哪种风格更好。最重要的,也是最需要我们做到的,是在团队、项目中保持风格统一,让代码像同一个人写出来的,整齐划一。这样能减少阅读干扰,提高代码的可读性。这才是我们在实际工作中想要实现的目标。

关于代码风格,我总结了6点我认为最值得关注的,今天跟你一块讨论学习一下。

# 1.类、函数多大才合适?

总体上来讲,类或函数的代码行数不能太多,但也不能太少。类或函数的代码行数太多,一个类上千行,一个函数几百行,逻辑过于繁杂,阅读代码的时候,很容易就会看了后面忘了前面。相反,类或函数的代码行数太少,在代码总量相同的情况下,被分割成的类和函数就会相应增多,调用关系就会变得更复杂,阅读某个代码逻辑的时候,需要频繁地在n多类或者n多函数之间跳来跳去,阅读体验也不好。

那一个类或函数有多少行代码才最合适呢?

我们在中提到过,要给出一个精确的量化值是很难的。当时我们还跟做饭做了类比,对于“放盐少许”中的“少许”,即便是大厨也很难告诉你一个特别具体的量值。

对于函数代码行数的最大限制,网上有一种说法,那就是不要超过一个显示屏的垂直高度。比如,在我的电脑上,如果要让一个函数的代码完整地显示在IDE中,那最大代码行数不能超过50。这个说法我觉得挺有道理的。因为超过一屏之后,在阅读代码的时候,为了串联前后的代码逻辑,就可能需要频繁地上下滚动屏幕,阅读体验不好不说,还容易出错。

对于类的代码行数的最大限制,这个就更难给出一个确切的值了。我们在第15讲中也给出了一个间接的判断标准,那就是,当一个类的代码读起来让你感觉头大了,实现某个功能时不知道该用哪个函数了,想用哪个函数翻半天都找不到了,只用到一个小功能要引入整个类(类中包含很多无关此功能实现的函数)的时候,这就说明类的行数过多了。

# 2.一行代码多长最合适?

在文档中,一行代码最长限制为100个字符。不过,不同的编程语言、不同的规范、不同的项目团队,对此的限制可能都不相同。不管这个限制是多少,总体上来讲我们要遵循的一个原则是:一行代码最长不能超过IDE显示的宽度。需要滚动鼠标才能查看一行的全部代码,显然不利于代码的阅读。当然,这个限制也不能太小,太小会导致很多稍长点的语句被折成两行,也会影响到代码的整洁,不利于阅读。

# 3.善用空行分割单元块

对于比较长的函数,如果逻辑上可以分为几个独立的代码块,在不方便将这些独立的代码块抽取成小函数的情况下,为了让逻辑更加清晰,除了上一节课中提到的用总结性注释的方法之外,我们还可以使用空行来分割各个代码块。

除此之外,在类的成员变量与函数之间、静态成员变量与普通成员变量之间、各函数之间、甚至各成员变量之间,我们都可以通过添加空行的方式,让这些不同模块的代码之间,界限更加明确。写代码就类似写文章,善于应用空行,可以让代码的整体结构看起来更加有清晰、有条理。

# 4.四格缩进还是两格缩进?

“PHP是世界上最好的编程语言?代码换行应该四格缩进还是两格缩进?”这应该是程序员争论得最多的两个话题了。据我所知,Java语言倾向于两格缩进,PHP语言倾向于四格缩进。至于到底应该是两格缩进还是四格缩进,我觉得这个取决于个人喜好。只要项目内部能够统一就行了。

当然,还有一个选择的标准,那就是跟业内推荐的风格统一、跟著名开源项目统一。当我们需要拷贝一些开源的代码到项目里的时候,能够让引入的代码跟我们项目本身的代码,保持风格统一。

不过,我个人比较推荐使用两格缩进,这样可以节省空间。特别是在代码嵌套层次比较深的情况下,累计缩进较多的话,容易导致一个语句被折成两行,影响代码可读性。

除此之外,值得强调的是,不管是用两格缩进还是四格缩进,一定不要用tab键缩进。因为在不同的IDE下,tab键的显示宽度不同,有的显示为四格缩进,有的显示为两格缩进。如果在同一个项目中,不同的同事使用不同的缩进方式(空格缩进或tab键缩进),有可能会导致有的代码显示为两格缩进、有的代码显示为四格缩进。

# 5.大括号是否要另起一行?

左大括号是否要另起一行呢?这个也有争论。据我所知,PHP程序员喜欢另起一行,Java程序员喜欢跟上一条语句放到一起。具体代码示例如下所示:

// PHP
class ClassName
{
    public function foo()
    {
        // method body
    }
}

// Java
public class ClassName {
  public void foo() {
    // method body
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

我个人还是比较推荐,将括号放到跟语句同一行的风格。理由跟上面类似,节省代码行数。但是将大括号另起新的一行的方式,也有它的优势。这样的话,左右括号可以垂直对齐,哪些代码属于哪一个代码块,更一目了然。

不过,还是那句话,大括号跟上一条语句在同一行,还是另起新的一行,只要团队统一、业内统一、跟开源项目看齐就好了,没有绝对的优劣之分。

# 6.类中成员的排列顺序

在Java类文件中,先要书写类所属的包名,然后再罗列import引入的依赖类。在Google编码规范中,依赖类按照字母序从小到大排列。

在类中,成员变量排在函数的前面。成员变量之间或函数之间,都是按照“先静态(静态函数或静态成员变量)、后普通(非静态函数或非静态成员变量)”的方式来排列的。除此之外,成员变量之间或函数之间,还会按照作用域范围从大到小的顺序来排列,先写public成员变量或函数,然后是protected的,最后是private的。

不过,不同的编程语言中,类内部成员的排列顺序可能会有比较大的差别。比如C++中,成员变量会习惯性放到函数后面。除此之外,函数之间的排列顺序,会按照刚刚我们提到的作用域的大小来排列。实际上,还有另外一种排列习惯,那就是把有调用关系的函数放到一块。比如,一个public函数调用了另外一个private函数,那就把这两者放到一块。

# 重点回顾

好了,今天的内容到此就讲完了。我们一块来总结回顾一下,你需要重点掌握的内容。这一节课我们通过6点,来给你讲了代码风格中的注意点。

1.函数、类多大才合适?

函数的代码行数不要超过一屏幕的大小,比如50行。类的大小限制比较难确定。

2.一行代码多长最合适?

最好不要超过IDE显示的宽度。当然,限制也不能太小,太小会导致很多稍微长点的语句被折成两行,也会影响到代码的整洁,不利于阅读。

3.善用空行分割单元块

对于比较长的函数,为了让逻辑更加清晰,可以使用空行来分割各个代码块。在类内部,成员变量与函数之间、静态成员变量与普通成员变量之间、函数之间,甚至成员变量之间,都可以通过添加空行的方式,让不同模块的代码之间的界限更加明确。

4.四格缩进还是两格缩进?

我个人比较推荐使用两格缩进,这样可以节省空间,特别是在代码嵌套层次比较深的情况下。除此之外,值得强调的是,不管是用两格缩进还是四格缩进,一定不要用tab键缩进。

5.大括号是否要另起一行?

我个人还是比较推荐将大括号放到跟上一条语句同一行的风格,这样可以节省代码行数。但是,将大括号另起一行,也有它的优势,那就是,左右括号可以垂直对齐,哪些代码属于哪一个代码块,更加一目了然。

6.类中成员的排列顺序

在GoogleJava编程规范中,依赖类按照字母序从小到大排列。类中先写成员变量后写函数。成员变量之间或函数之间,先写静态成员变量或函数,后写普通变量或函数,并且按照作用域大小依次排列。

今天讲到所有的代码风格都没有对错和优劣之分,只要能在团队、项目中统一即可,不过,最好能跟业内推荐的风格、开源项目的代码风格相一致。

# 课堂讨论

聊一聊你熟悉的编程语言的代码风格,比如是四格缩进还是两格缩进?试着给自己的项目整理一份编程规范。

欢迎在留言区写下你的答案,和同学一起交流和分享。如果有收获,也欢迎你把这篇文章分享给你的朋友。

# 精选评论

点击查看

辣么大

这阵争哥节奏放缓,大家都能歇歇。前些篇文章确实硬核。我每篇看下来加查资料来至少要两个小时,总这么整谁能扛得住呀。争哥加油!


何用

“不管是用两格缩进还是四格缩进,一定不要用tab键缩进。” ——— 老师的这个观点我持相反的意见。我是推崇使用tab缩进的,这样每个人可以根据自己的喜好,在IDE自行定义一个tab在视觉上等于几个空格,富于弹性。至于tab和空格缩进可能混用的问题,工具可以很好地帮我们解决。


Jeff.Smile


守候、


Binary


火车日记

提问:返回前端接口中的key的书写风格,是和变量名的驼峰风格保持一致,还是和表中字段下划线式的风格保持一致?


qinsi


守拙

补充一点:<GoogleJavaStyleGuide>中明确要求:

Tab不能用于缩进.

原文: 2.3.1Whitespacecharacters 2.Tabcharactersarenotusedforindentation.

从今日起,改掉坏习惯,不再使用tab缩进.


守拙

简单看了下<GoogleJavaStyleGuide>:

源代码文件使用utf-8编码.

这一点容易被忽略,但还是挺重要的.


小可

既然是规范,就不是为了表达个性化的代码风格。花括号同行还是换行,缩进两格还是四格,现实当中没有绝对的标准,只要在公司或部门内统一就行,即使换了地方,标准不一样只要统一,适应几天就好了。不然每次更新代码,都要格式化,提交后连上次修改的地方都找不出来,因为diff出来全变了😂


李小四

设计模式_32

缩进这个我要看一下了,因为一直都用tab缩进,可能是团队中都习惯tab缩进(并没有规定),所以没遇见过问题。

有的时候,代码风格没有优劣,统一的风格就像统一度量衡,光是统一就带来错误率降低和效率提升。


Kang

打卡


黄林晴


Jackey


qwerboo

不,我就要用四个空格😏


唐龙


javaadu

我基本就按照阿里巴巴的编码规范来,在此之外才会“自由”发挥,不过这部分也会尽量做到项目内部统一


aof


落叶飞逝的恋


Dimple


#极客时间
上次更新: 2025/06/04, 15:06:15
理论五:让你最快速地改善代码质量的20条编程规范(上)
理论五:让你最快速地改善代码质量的20条编程规范(下)

← 理论五:让你最快速地改善代码质量的20条编程规范(上) 理论五:让你最快速地改善代码质量的20条编程规范(下)→

最近更新
01
AIIDE
03-07
02
githubActionCICD实战
03-07
03
windows安装Deep-Live-Cam教程
08-11
更多文章>
Theme by Vdoing
总访问量 次 | 总访客数 人
| Copyright © 2021-2025 ggball | 赣ICP备2021008769号-1
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式
×

评论

  • 评论 ssss
  • 回复
  • 评论 ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
  • 回复
  • 评论 ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
  • 回复
×