《设计模式之美》 改善代码质量的编程规范
一、命名
1.命名长度
命名要准确达意，千万不要有“反正代码是我写的，我明白什么意思，随便起名就可以了”这样的误解，毕竟同事也会看我们的代码。
对于一些长常用的单词，可以用缩写，这样可以保证既等达意又减少了命名的长度。
对于一些作用域小的变量比如函数内的临时变量，可以使用短一些命名，对于作用域大的变量，最好还是用长命名的方式
2.利用上下文简化命名
类的属性可以借助类这个上下文、方法参数可以借助方法这个上下文
3.命名要可读、可搜索
可读是指不要用一些生僻、难发音的单词，这样可以有效减少同事之间的沟通负担
可搜索就是便于根据关键字查类似的方法或变量等，比如查询类方法 输入select或query，这里要注意的是代码风格要一致即查询相关的用了slect就不要用query，反之亦然
4.命名接口和抽象类
接口有两种命名方式
①接口加前缀“I”，例如接口 IUserService，实现类为UserService
②实现类加后缀“Impl”，例如接口 UserService，实现类为UserServiceImpl
至于选哪种，项目中统一就好
二、注释
1.注释该写的内容
注释的目的是让代码容易看懂，所以注释的内容主要包括：做什么、为什么、怎么做三个部分，对应一些复杂的类和接口，最好也写上如何做即demo
2.注释写的越来越多越好吗？
注释肯定不是越多越好，因为有时代码逻辑有改动，如果注释写的太多，也需要维护，也是一件麻烦事儿。类和函数要写注释，并且要尽量写的全面和详细。函数内部的注释可以相对减少一些，靠好的命名、提炼函数、解释性变量、总结性注释来提高代码的可读性
三、代码风格
1.类、函数多少行才合适？
类、函数行数太多容易造成看到后面忘掉前面，行数太少的话一般是切分类或函数响应就会增加，调用关系变复杂，阅读时来回跳跃，可读性也不高。所以这个很难给出确切值，一般是不要超过一个显示屏的垂直高度就好了。
2.一行代码多长合适？
最好别超过IDE显示的宽度，减少滑动。也不要太短，容易换行
3.善于用空格分隔单元块
4.大括号是否要另起一行？
另起一行可以使左右括号垂直对齐，方便查阅哪些代码属于一个代码块。不另起一行可以节省代码行数，我个人倾向于不另起一行
四、编程技巧
1.将复杂的逻辑提炼出类或函数
一些逻辑很复杂，单看代码可能摸不着头脑，如果把这个复杂逻辑提炼成类或函数，在通过起一个达意的命名，在调用方就很容易知道代码是干嘛的
2.函数的参数不易过多
如果函数的参数过多（如最好别超过5个），会降低可读性，并且使用也不方便，针对这种情况可以采用如下的两种方法
①如果函数功能单一，可以通过拆分成多个函数的方法来减少函数的参数
②将函数的参数封装成对象，一般在设计接口时都是采用这种方法
3.函数中不要使用参数来做代码逻辑的控制
这点我经常犯，通过boolean类型的参数在函数中做逻辑控制。这样违反了单一职责原则和接口隔离原则。这种可以拆成多个函数。
不过如果函数是私有的，影响范围小或者拆分后的两个函数经常会被同时调用，可以适当保留参数
除了boolean类型的参数做逻辑控制，还有通过判断是会否为null做逻辑控制，这种情况也要拆分成多个函数
4.函数职责要单一
5.避免多层嵌套（常见的if-else、switch-case、for循环）
解决多层嵌套可参考的方法如下
①去掉多余的if或else语句
比如在if中有了return，那么else就是多余的。还有一种是多个if的判断可以合并起来
②用continue、break、return 等关键字，提前退出嵌套
③通过调整执行顺序减少嵌套
对集合我们经常会有非null判断和非空判断，然后在执行后续逻辑，这种情况可以通过先对null或空的情况做判断，并提前返回
④将部分嵌套逻辑封装成函数调用
6.使用解释性变量
①用常量替换魔法数字
②使用解释性变量代替复杂的表达式
参考资料
《设计模式之美》
来源：CSDN
作者：每天晒白牙
链接：https://blog.csdn.net/dam454450872/article/details/104135731