前言
根据《代码整洁之道》提取的一些书籍中的要点，根据自己习惯整理，可能对于他人不适用。整理了大部分要点，关于代码重构和代码味道的部分没有整理，在读code smell的时候再整理这部分。
整洁代码
代码的不可替代性
代码呈现了需求的细节，只有代码能够将需求明确到机器可以执行的程度什么是糟糕的代码
可能是因为赶时间，来不及做代码的重构，想要留到后面再做，导致代码越来越“混乱”。稍后等于用不（Later equals never）糟糕代码的代价
后期无法清理
新人难以上手
生产力不断下降
整洁代码的特性
优雅（命名，不重复）
读代码，能够让人愉悦，而不是眉头紧锁效率（测试）
尽量不浪费运算周期完善错误处理
在细节上花心思只做好一件事（函数大小，不发散）
每个函数、每个类和每个模块都应该全神贯注与一件事，不受四周细节的干扰和污染可增补性
错误处理
使用异常
函数不返回null
参数不传递null
对象和数据结构
对象暴露行为，隐藏数据
数据结构暴露数据，没有明显的行为
格式
善用IDE格式化工具
团队规则统一
注释
注释不能美化代码
尽量用代码来阐述
可用的注释
法律信息
对意图的解释
警示
Todo注释
代码Doc
需要避免的注释
多余的注释
误导性注释
循规式注释
可以用函数或变量代替的注释
注释掉的代码
和当前代码没有联系的注释
函数
短小
最大行数20只做一件事
函数应该做一件事，并且做好这件事。判断函数是否不止做了一件事，可以看是否还能拆出一个函数，而该函数不仅是重新诠释实现switch语句
尽量将switch语句埋到抽象工厂下面，用多态代替使用描述性的名称
函数参数不要超过3个
理解参数的成本，测试的成本抽离Try/Catch代码块
结构化编程
代码块应该有一个入口、一个出口
命名
名副其实
如果名称需要注释来补充，那么它就不算名副其实避免误导
有意义的区分
如a作为域内变量，the用于函数参数使用可搜索的名称
避免使用编码
如接口需要加 I 前缀，成员变量加m_前缀类名
类名和对象名应该是名词或者名词短语，指代它代表的含义，不应该是动词方法名
方法名应该是动词或者动词短语，指代要做的事情每个概念对应一个词
添加有意义的语境
单元测试
TDD三定律
在编写不能通过的单元测试前，不可编写生产代码
只可编写刚好无法通过的单元测试，不能编译也算不通过
只可编写刚好足以通过当前失败测试的生产代码
保持可读性
Given-When-Then的结构
每个测试只包含一个概念
F，I，R，S，T（Fast, Independent, Repeatable, Self-Validating, Timely）
类
短小
避免出现supper class单一权责原则
内聚
系统
工厂
不关心其内部实现依赖注入(DI)
优化决策
迭进
简单设计
运行所有测试
不可重复
表达意图
尽可能减少类和方法的数量
以上规则按其重要程度排列
并发
并发相关代码有自己的开发、修改和调优生命周期
开发相关代码有自己要对付的挑战，和并发相关代码不同，而且往往更为困难
并发防御原则
限制数据作用域
单一权责
使用数据副本
线程尽可能独立
执行模型
基础定义
限定资源
互斥
线程饥饿
死锁
活锁
生产者-消费者模型
读者-作者模型
宴席哲学家
测试
足够的测试
使用覆盖率工具
别略过小测试
被忽略的测试就是对不确定事物的疑问
测试边界条件
全面测试相近的缺陷
测试失败的模式有启发性
测试覆盖率的模式有启发性
测试应该快速