【杂谈】Clean Code 代码整洁之道学习总结

1.减少重复代码，提高表达力，提早构建简单抽象

2.有意义的命名：

（1）名副其实，模糊的代码就是反例，

（2） 避免误导，比如有些字母组合是其他语言的关键字，l 和 o  尽量不用；

（3）使用读得出来的名称

（4）使用可搜索的名称

（5）避免使用编码

（6）避免成员前缀  比如m_xxx

（7）接口和实现

（8）避免思维映射

（9）类名是名词，方法名是动词

（10）每个概念对应一个词

（11）别用双关语

（12）使用解决方案领域名称

（13）使用所涉问题领域的名称

（14）添加有意义的语境         addFirstName  addLastName

（15）不要添加没用的语境，不要有歧义

（16）名称与抽象层级相符

（17）较大作用范围选用较长较准确的名称

3.函数（方法）

（1）函数的第一规则是短小

（2）只做一件事,做好一件事

（3）每个函数一个抽象层级

（4）自顶向下读代码，向下原则

（5）短小的Switch语句

（6）使用描述性的名称，长而具有描述性的名称比短小令人费解的名字好

（7）命名方式保持一致，使用与模块名称一脉相承的短语、名词、动词给函数命名

（8）函数的参数，越少越好

（9）标示参数，带boolean值的情况，最好一份为二，不建议使用带boolean值情况

（10）二元函数 三元函数需要小心 ，参数对象的命名，是否需要多元函数，参数的顺序是否好记，符合常规

（11）无副作用

（12）输出参数

（13）错误处理就是一件事

（14）结构化编程     即小的函数只能有一个return

（15）避免否定性条件

（16）名称应该说明副作用

4.注释

（1）别给糟糕的代码加注释，重新写吧

（2）法律信息

（3）提供信息的注释

（4）对意图的注释

（5）阐释   如 if(a.compare(b) == 0)    //a==b

（6）警示

（7）TODO注释

（8）坏注释之喃喃自语

（9）坏注释之多余的注释

（10）坏注释之误导性注释

（11）xunguishizhushi

（12）日志式注释

（13）坏注释之废话注释

（14）能用函数或变量时就别用注释

（15）坏注释之位置标记

（16）坏注释之括号后面的注释

（17）坏注释之注释掉的代码

（18）坏注释之HTML注释

（19）坏注释之非本地信息

（20）坏注释之信息过多

5.格式

（1）垂直格式，向报纸学习

（2）水平对齐

6.对象和数据结构

7.边界

（1）使用第三方代码

（2）浏览和学习边界：在使用第三方代码之前需要测试是否可用

8.单元测试

整洁的测试包含5个原则

（1）快速

（2）独立

（3）可重复

（4）自足验证

（5）及时

9.类

（1）封装性

（2）短小，尽量不超过70个方法

（3）单一权责原则

10.系统

11.简单设计原则

（1）运行所有测试

（2）不可重复

（3）表达了程序员的意图

（4）尽可能减少方法和类的数目

12.测试

（1）测试不足

（2）使用覆盖率工具

（3）别略过小测试

（4）测试边界条件

（5）全面测试相近的缺陷

（6）测试失败的模式是否具有启发

（7）测试覆盖率模式是否有启发性

（8）测试应该快速