编程规范
2022-07-07 11:33:32 0 举报
AI智能生成
Java编程规范
作者其他创作
大纲/内容
命名
命名多长最合适?
在足够表达其含义的情况下,命名当然是越短越好。但是,大部分情况下,短的命名都没有长的命名更能达意。所以,很多书籍或者文章都不推荐在命名时使用缩写。对于一些默认的、大家都比较熟知的词,我比较推荐用缩写。这样一方面能让命名短一些,另一方面又不影响阅读理解,比如,sec 表示 second、str 表示 string、num 表示 number、doc 表示 document。除此之外,对于作用域比较小的变量,我们可以使用相对短的命名,比如一些函数内的临时变量。相反,对于类名这种作用域比较大的,我更推荐用长的命名方式。
利用上下文简化命名
示例
User
借助上下文
函数参数也可以借助函数这个上下文来简化命名
示例
命名要可读、可搜索
可读
让大部分人看一眼就能知道怎么读,不至于提到项目的名字的时候,都会尴尬地卡顿一下。
可搜索
大家都用“selectXXX”表示查询,你就不要用“queryXXX”;大家都用“insertXXX”表示插入一条数据,你就要不用“addXXX”,统一规约是很重要的,能减少很多不必要的麻烦。
如何命名接口和抽象类?
接口
一种是加前缀“I”,表示一个 Interface。比如 IUserService,对应的实现类命名为 UserService。
另一种是不加前缀,比如 UserService,对应的实现类加后缀“Impl”,比如 UserServiceImpl。
注释
注释到底该写什么?
做什么
当方法名称、类名称不够详尽时,注释可以起到补充的作用
为什么
阐述这样做是为了达到什么目的,或者避免什么bug
怎么做
对于具体的实现,可以写一些总结性的注释,在读代码的时候,更加清楚意图
示例
BeansFactory注释
注释是不是越多越好?
类和函数一定要写注释,而且要写得尽可能全面、详细,而函数内部的注释要相对少一些,一般都是靠好的命名、提炼函数、解释性变量、总结性注释来提高代码的可读性。
代码风格
类、函数多大才合适?
当一个类的代码读起来让你感觉头大了,实现某个功能时不知道该用哪个函数了,想用哪个函数翻半天都找不到了,只用到一个小功能要引入整个类(类中包含很多无关此功能实现的函数)的时候,这就说明类的行数过多了。
一行代码多长最合适?
一行代码最长不能超过 IDE 显示的宽度。需要滚动鼠标才能查看一行的全部代码,显然不利于代码的阅读。当然,这个限制也不能太小,太小会导致很多稍长点的语句被折成两行,也会影响到代码的整洁,不利于阅读。
善用空行分割单元块
,在类的成员变量与函数之间、静态成员变量与普通成员变量之间、各函数之间、甚至各成员变量之间,我们都可以通过添加空行的方式,让这些不同模块的代码之间,界限更加明确。
四格缩进还是两格缩进?
个人比较推荐使用两格缩进,这样可以节省空间。特别是在代码嵌套层次比较深的情况下,累计缩进较多的话,容易导致一个语句被折成两行,影响代码可读性。
一定不要用 tab 键缩进。因为在不同的 IDE 下,tab 键的显示宽度不同,有的显示为四格缩进,有的显示为两格缩进。如果在同一个项目中,不同的同事使用不同的缩进方式(空格缩进或 tab 键缩进),有可能会导致有的代码显示为两格缩进、有的代码显示为四格缩进。
大括号是否要另起一行?
个人还是比较推荐,将括号放到跟语句同一行的风格。理由跟上面类似,节省代码行数。
类中成员的排列顺序
在类中,成员变量排在函数的前面。成员变量之间或函数之间,都是按照“先静态(静态函数或静态成员变量)、后普通(非静态函数或非静态成员变量)”的方式来排列的。除此之外,成员变量之间或函数之间,还会按照作用域范围从大到小的顺序来排列,先写 public 成员变量或函数,然后是 protected 的,最后是 private 的。
把代码分割成更小的单元块
大部分人阅读代码的习惯都是,先看整体再看细节。所以,我们要有模块化和抽象思维,善于将大块的复杂逻辑提炼成类或者函数,屏蔽掉细节,让阅读代码的人不至于迷失在细节中,这样能极大地提高代码的可读性。不过,只有代码逻辑比较复杂的时候,我们其实才建议提炼类或者函数。毕竟如果提炼出的函数只包含两三行代码,在阅读代码的时候,还得跳过去看一下,这样反倒增加了阅读成本。
示例
避免函数参数过多
函数包含 3、4 个参数的时候还是能接受的,大于等于 5 个的时候,我们就觉得参数有点过多了,会影响到代码的可读性,使用起来也不方便。
处理方案
考虑函数是否职责单一,是否能通过拆分成多个函数的方式来减少参数。
示例
将函数的参数封装成对象。
示例
勿用函数参数来控制逻辑
情况一
不要在函数中使用布尔类型的标识参数来控制内部逻辑,true 的时候走这块逻辑,false 的时候走另一块逻辑。这明显违背了单一职责原则和接口隔离原则。
处理方案
建议将其拆成两个函数,可读性上也要更好。
示例
情况二
如果函数是 private 私有函数,影响范围有限,或者拆分之后的两个函数经常同时被调用,我们可以酌情考虑保留标识参数。
示例
情况三
还有一种“根据参数是否为 null”来控制逻辑的情况。针对这种情况,
处理方案
我们也应该将其拆分成多个函数。拆分之后的函数职责更明确,不容易用错
示例
函数设计要职责单一
我们在前面讲到单一职责原则的时候,针对的是类、模块这样的应用对象。实际上,对于函数的设计来说,更要满足单一职责原则。相对于类和模块,函数的粒度比较小,代码行数少,所以在应用单一职责原则的时候,没有像应用到类或者模块那样模棱两可,能多单一就多单一。具体的代码示例如
示例
移除过深的嵌套层次
代码嵌套层次过深往往是因为 if-else、switch-case、for 循环过度嵌套导致的。我个人建议,嵌套最好不超过两层,超过两层之后就要思考一下是否可以减少嵌套。过深的嵌套本身理解起来就比较费劲,除此之外,嵌套过深很容易因为代码多次缩进,导致嵌套内部的语句超过一行的长度而折成两行,影响代码的整洁。
处理方案
去掉多余的 if 或 else 语句。
示例
使用编程语言提供的 continue、break、return 关键字,提前退出嵌套。
示例
调整执行顺序来减少嵌套
示例
将部分嵌套逻辑封装成函数调用,以此来减少嵌套
示例
常用的还有通过使用多态来替代 if-else、switch-case 条件判断的方法
学会使用解释性变量
常量取代魔法数字
示例
使用解释性变量来解释复杂表达式
示例
0 条评论
下一页