《设计模式之美》第四章 总结

《设计模式之美》第四章 总结

第四章 代码规范

4.1 命名与注释：如何精准命名和编写注释

4.1.1 长命名和短命名哪个更好

谨慎使用缩写
作用域比较小的变量，比如临时变量，可以说使用短命名
作用域比较大的变量，比如全局变量，推荐使用长命名
1
2
3

4.1.2 利用上下文信息简化命名

4.1.3 利用业务词汇表统一命名

4.1.4 命名既要精准又要抽象

命名不要太过宽泛表意不精准，也不能过于具体，透露太多实现细节；
只需要表明做什么，而不需要表面怎么做；
要兼顾抽象特性，在修改具体实现时，可以不用修改它的命名；
1
2
3

4.1.5 注释应该包含哪些内容

应该包含：做什么、为什么、怎么做
作用：	
1. 注释可以承载比命名更多的信息
2. 注释有说明和示范作用
3. 总结性注释可以使代码逻辑更加清晰
1
2
3
4
5

4.1.6 注释并非越多越好

注释太多，会导致很高的维护成本，修改了代码忘记改注释，会导致代码和注释不一致
类、函数、成员变量，需要写详尽的注释
内部代码：局部变量、函数内部每条语句，尽量少写注释
通过好的命名、函数拆分、解释性变量来替代注释；
1
2
3
4

4.2 代码风格：与其争论标准，不如团队统一

4.2.1 类、函数多大才合适

什么时候该拆分：当感到阅读一个类的代码困难、实现某个功能时不知道应该使用类中的哪个函数、需要很长时间寻找函数和使用一个小功能却要引入一个庞大的类（类中包含很多与此功能实现无关的函数），说明类的代码行数过多了
1

4.2.2 一行代码多长才合适

最好不要超过IDEA显示的宽度
1

4.2.3 善用空行分隔代码块

在成员变量和函数之间
静态成员变量和普通成员变量之间
各个函数之间、各成员变量之间
1
2
3

4.2.4 是四格缩进还是两格缩进

4.2.5 左大括号是否要另起一行

团队或项目中保持统一
1

4.2.6 类中成员的排列顺序

成员变量在函数前面
成员变量和函数之间：先静态、后非静态
成员变量和函数之间还会按照作用域范围从大到小顺序排列：先publie，后protected, 最后private
1
2
3

4.3 编程技巧：小技巧，大作用，一招提高代码的可读性

4.3.1 将复杂的代码模块化

要有模块化思维：善于将大块的复杂代码封装成类或函数，提高代码的可读性
1

4.3.2 避免函数的参数过多

一般超过5个算多
解决方法：将参数封装为对象的方式，可以减少参数个数、提高函数兼容性（加参数不需要改变函数定义，只需要修改参数对象）
1
2

4.3.3 移除函数中的flag参数

可以拆分成两个或多个函数，拆分后函数的职责明确；
1

4.3.4 移除嵌套过深的代码

嵌套最好不要超过两层
处理方法：
1. 去掉冗余的if-else语句；
2. 使用continue、break和return关键字提前退出嵌套；
3. 通过调整执行顺序减少嵌套层数；
4. 将部分嵌套代码封装成函数，减少嵌套层数；
1
2
3
4
5
6

4.3.5 学会使用注释性变量

1. 使用常量取代魔法数字
2. 使用解释性变量来解释复杂表达式；
1
2