CLean Code ——代码整洁之道

第1章 整洁代码

1. 能通过所有测试
2. 没有重复的代码
3. 体现系统中的全部设计理念
4. 包括尽量少的实体，比如类、方法、函数等

第2章 有意义的命名

第3章 函数

1. 短小
2. 只做一件事
3. 每个函数一个抽象层级
4. Switch语句
5. 使用描述性的名称
6. 函数参数（尽可能少）
7. 无副作用
8. 分割指令与询问
9. 使用异常替代返回错误码：try/catch
10. 别重复自己
11. 结构化编程：函数中每个代码块都应该有一个入口、一个出口。每个函数只该有一个return语句，循环中不能有break或continue语句。

第4章 注释

1. 注释不能美化糟糕的代码
2. 用代码来阐述
3. 好注释：法律信息、提供信息的注释、对意图的注释、阐释、警示、 TODO注释（解释了为什么该函数的实现部分无所作为，将来应该是怎样）、放大（突出重要性）、公共API中的Javadoc。
4. 坏注释：楠楠自语、多余的注释、误导性注释、循规式注释、日志式注释、废话注释

第5章 格式

1. 格式的目的：提高代码的可读性
2. 垂直格式
3. 横向格式
4. 团队规则
5. 鲍勃大叔的格式规则

第6章 对象和数据结构

1. 数据抽象
   不愿曝露数据细节，更愿意以抽象形态表述数据。
   曝露行为，隐藏数据。
2. 数据、对象的反对称性
3. 得墨忒耳律
4. 数据传送对象

第7章 错误处理

1. 使用异常而非返回码
2. 先写Try-Catgch-Finally语句
3. 使用不可控异常
4. 给出异常发生的环境说明
5. 依调用者需要定义异常类
6. 定义常规流程
7. 别返回null值
8. 别传递null值

第8章 边界

1. 使用第三方代码
2. 浏览和学习边界
3. 学习性测试(帮助我们增进对API的理解)
4. 整洁的边界

第9章 单元测试

1. TDD(测试驱动开发)三定律
   定律一：在编写不能通过的单元测试前，不可编写生产代码。
   定律二：只可编写刚好无法通过的单元测试，不能编译也算不通过。
   定律三：只可编写刚好足以通过当前失败测试的生产代码。
2. 保持测试整洁
3. 整洁的测试：可读性
4. 每个测试一个断言
5. F.I.R.S.T：快速（Fast）、独立（Independent）、可重复（Repeatable）、自足验证（Self-Validating）、及时（Timely）

第10章 类

1. 类的组织
2. 类应该短小：SRP单一权责原则(类或模块应有且只有一条加以修改的理由)、内聚、保持内聚性就会得到许多短小的类
3. 为了修改而组织

第11章 系统

1. 将系统的构造与使用分开
2. 分解main
3. 扩容
4. Java代理
5. 纯Java AOP框架
6. AspectJ的方面
7. 测试驱动系统架构
8. 优化决策
9. 明智使用添加了可论证价值的标准
10. 系统需要领域特定语言

第12章 跌进