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

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

第四章 代码规范

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

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

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

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

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

4.1.4 命名既要精准又要抽象

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

4.1.5 注释应该包含哪些内容

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

4.1.6 注释并非越多越好

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

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

4.2.1 类、函数多大才合适

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

4.2.2 一行代码多长才合适

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

4.2.3 善用空行分隔代码块

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

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

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

团队或项目中保持统一

4.2.6 类中成员的排列顺序

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

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

4.3.1 将复杂的代码模块化

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

4.3.2 避免函数的参数过多

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

4.3.3 移除函数中的flag参数

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

4.3.4 移除嵌套过深的代码

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

4.3.5 学会使用注释性变量

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