业务codeClean
单一职责
不要为了可以节省一段代码而将功能写成大杂烩的方法。
一个方法只做一件事,做好一件事。
错误用例:
.png)]
在这个场景中将两个功能组成一个方法,并使用type来控制接口的功能。
类似这种完全就是两个功能的接口应该直接分为两个接口(排除特殊需求的原因)。
不易理解的判断条件
错误用例
不易理解的判断条件,将判断条件进行封装。
命名为hasCloseAccount,见名知意,可以理解为是否关闭账单
更新后
jdk源码中的案例
方法加上注释
方法应该加上注释
注释是有必要的,应该养成写注释,写好注释的习惯
错误用例
换行的重要性
换行增强代码的可读性,以代码的功能作为最小单位进行换行
功能相似的代码之间不需要换行
错误用例1
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sgWHXuJT-1686709527683)(.\iamge\换行错误用例.png)]
不要为了换行而换行
错误用例2
更新后
错误用例3
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qSTwSVsc-1686709527683)(.\iamge\换行的重要性错误用例.png)]
更新后
spring源码案例
fastFail 快速失败
尽量减少if条件的嵌套、
使用fastFail可以尽可能的避免不必要的代码嵌套
错误用例
更新后
错误用例2
JDK源码案例
表达不切意的注释&不必要的注释
在codeClean中的一个理论,表达的意思大致是:好的代码可以不需要注释,如果你发现不得不写注释时应该回头看看是不是代码写的太糟糕了。
个人认为注释还是需要的,虽然清晰的逻辑和简明的命名可以代替注释。
但是对于国内开发者来说,即使命名多么具有概况性,由于英文水平的参差不齐会导致我们领略不了有些优美的命名
所以对于国内的开发者,我觉得是有必要加上注释的
错误用例
注释写的是查询订舱信息但是代码逻辑是批量更新
注释的表达与代码逻辑体现不一致
这里应该是注释应该是为上一行的代码写的,但是由于更新后注释的位置没有调整
同时,这种不必要的注释可以不必要写,因为这一行很轻易能理解它是为了查询订舱信息,不要为了写注释而写注释。这里写上也可以,没有找到更好的例子,单纯举个例子
代码与代码的位置调整
将变量与变量使用处的代码尽可能的放在一块
将方法与方法调用处放在一块
目的是为了在阅读代码时跳跃性不会太大,增强代码可读性
错误用例
有些开发者习惯于,将待使用的变量先在前面进行罗列,然后再后面使用时方便调用
但是在变量的使用时应该将变量一起调整
更新后
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d6F65di8-1686709527684)(.\iamge\代码与代码之间的位置更新后.png)]
这样的好处是,在阅读代码时,如果不明白变量是什么,可以快速定位并理解变量的作用,因为它就在上方
函数的第一规则是要短小,第二规则是还要更短小
函数应该尽可能的短小
过长的函数大多数的原因是没有进行功能点方法的抽离
错误用例
注释写明了各个代码块的功能点,按照功能点,应该将代码块进行方法封装。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uGwMqTvH-1686709527684)(C:\Users\Administrator\Desktop\personal\note\业务codeClean\iamge\功能点没有进行抽离错误用例.png)]
错误用例2
代码块按功能进行方法封装
单行注释,多行注释,文档注释
正确的使用注释类型
-
单行注释
- 以双斜杠“//”标识,只能注释一行内容,用在注释信息内容少的地方。
-
多行注释
- 包含在“/*”和“*/”之间,能注释很多行的内容。为了可读性比较好,一般首行和尾行不写注释信息,这样也比较美观好看。
-
文档注释
- 包含在“/**”和“*/”之间,也能注释多行内容,一般用在类、方法和变量上面,用来描述其作用。注释后,鼠标放在类和变量上面会自动显示出我们注释的内容。
错误用例
修饰方法和类,尽量使用文档注释
for循环的嵌套
避免过多的for循环嵌套
错误用例
更新后
使用list的contains方法可以避免循环的嵌套
对象在使用之前需要进行非空判断
对象没有进行非空判断,直接使用对象的属性会导致出现空指针异常
错误用例
更新后
代码缩进
错误用例
多处使用的属性可以用一个变量存储
错误用例
更新后
按功能点将代码块进行封装
代码块按功能点进行方法封装
优秀的命名你甚至可以不读代码一眼就理解方法的作用
类似常用的mybatis的函数的命名:selectById、selectOne、selectList、selectCount
错误用例
更新后
例子3
更新后
jdk源码中的案例
spring中的案例
只有一行有必要封装一个方法?
如果可以增强阅读性,那么有必要
spring源码案例2
注释的代码需要及时处理
出于可能还需要用到的考虑,开发者会将暂时内容注释,以便后期方便还原
注释后的代码如果长时间没有处理,后期导致忘记了注释的目的,导致不敢删除
别的开发人员看到大片注释也不敢轻易删除,就会导致注释一直堆积
如果不需要的代码可以直接删除,如果后期需要还原可以查看git的log功能找回
案例
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AxPtIA8E-1686709527689)(.\iamge\注释代码及时处理错误用例.png)]
解决方案
查看git的代码修改日志
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vw5j7VD6-1686709527690)(.\iamge\注释代码及时处理解决方案.png)]
总结一下
-
单一职责
-
不要为了可以节省一段代码而将功能写成大杂烩的方法。
-
一个方法只做一件事,做好一件事。
-
-
不易理解的判断条件进行封装
-
注释的重要性
-
方法应该加上注释
-
注释是有必要的,应该养成写注释,写好注释的习惯
-
-
换行的重要性
-
fastFail
-
尽量减少if条件的嵌套、
-
使用fastFail可以尽可能的避免不需要的代码嵌套
-
-
表达不切意的注释
-
注释表达与代码逻辑不一致,导致的问题比不写注释更大
-
不切意的注释会欺骗开发者
-
-
不必要的注释
- 显而易见的代码逻辑不需要写注释
-
代码与代码的位置关系
-
变量与变量的调用处尽量靠近放一起
-
方法与方法调用处放在一起,按使用的顺序排列
-
-
函数需要短小
- 一个函数只做一件事,做好一件事
-
不同注释类型的使用场景
-
单行注释:
- 以双斜杠“//”标识,只能注释一行内容,用在注释信息内容少的地方。
-
多行注释:
- 包含在“/”和“/”之间,能注释很多行的内容。为了可读性比较好,一般首行和尾行不写注释信息,这样也比较美观好看。
-
文档注释:
- 包含在“/**”和“*/”之间,也能注释多行内容,一般用在类、方法和变量上面,用来描述其作用。注释后,鼠标放在类和变量上面会自动显示出我们注释的内容。
-
-
for循环、大量的if嵌套
- 尽量避免大量的for循环,if的嵌套
-
对象的非空判断
- 对象在使用之前需要进行非空判断,提高代码健壮性。容易出现空指针
-
代码的缩进(排版)
-
频繁使用的属性
-
功能点进行方法封装
-
将一个功能点的代码块进行方法的封装
-
命名的重要性,优秀的命名的好处
-
-
注释的代码及时处理
- 不要堆积注释代码,利用git log处理
最后让我们来问一下chatGpt吧
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AChDNYZS-1686709527690)(.\iamge\chatGpt提出的代码整洁的办法.png)]
内容,一般用在类、方法和变量上面,用来描述其作用。注释后,鼠标放在类和变量上面会自动显示出我们注释的内容。
-
for循环、大量的if嵌套
- 尽量避免大量的for循环,if的嵌套
-
对象的非空判断
- 对象在使用之前需要进行非空判断,提高代码健壮性。容易出现空指针
-
代码的缩进(排版)
-
频繁使用的属性
-
功能点进行方法封装
-
将一个功能点的代码块进行方法的封装
-
命名的重要性,优秀的命名的好处
-
-
注释的代码及时处理
- 不要堆积注释代码,利用git log处理