这本书要求经验比较丰富的Java经验。
整洁代码
- 知道许多关于代码的事了
- 好代码和坏代码之间的差异
要有代码
特性越加越多，代码也越来越烂，最后再也没法管理这些代码了。
稍后等于永不
混乱的代价
- 新设计会导致两套不同的方式，造成混乱
- 保持这样的态度：我最懂，你给的压力不对，我不会听从
- 消除重复和提高表达力
- 让营地比你来时更干净
有意义的命名
名副其实
- 需要用注释来补充的变量名不算名副其实
1
int d; // 消逝的时间，以日计
可以更改为1
int elapsedTimeInDays;
做有意义的区分
- a1, a2等命名方式没有提供正确或导向作者意图的线索
- Product/ProductInfo/ProductData等名称虽然不同，但是意思却无分别
- 废话都是冗余。如nameString可以改成name
- 不要自造词汇，使用英语词汇进行命名（可以读出来）
- 名字可搜索，数字5，单个单词等都不好搜索
- 类名应该为名词，方法名应该为动词
#函数
短小
- 长度为20-100行最佳
- if-else，while语句内的代码块应该尽量用函数包括，因为函数具有说明性的名称
- 函数只做一件事，做好这件事
- 函数无副作用
- 使用异常代替错误码
- 别重复自己
注释
不好的注释
- 注释并不一定就是好的，注释的恰当用法是弥补我们在用代码表达意图时遭遇到的失败，当必须要用注释时，看是否能用代码来表达
- 注释会撒谎，修改代码时并不一定会修改注释
- 不准确的注释不如不注释
好的注释
- 法律信息
- 信息的注释
- 对意图的注释
- 阐释，对晦涩难明的参数或返回值的意义翻译为某种可读的形式
- 警示
- TODO注释
对象和数据结构
得墨耳定律：模块不应该了解它所操作的对象的内部情况
错误处理
- 别返回null值
- 别传入null值（除非函数要求），但是，检查null值的责任应该由调用者负责还是函数负责呢？
边界
学习性测试的好处不止是免费，还在投资上有正面的回报；
依靠能控制的东西好过依靠不能控制的东西；
单元测试
- 没有测试之前不要写任何功能代码
- 只编写恰好能够体现一个失败情况的测试代码
- 只编写恰好能通过测试的功能代码
整洁的测试只有一个要求：可读性
F.I.R.S.T原则
- Fast：快速运行才会让人想运行它
- Independent：每个测试用例之间应该独立
- Repeatable：可重复的
- Self-Validating：测试用例自己可验证自己是否得到正确的结果
- Timely：测试用例应该及时编写
类
放松封装总是下策
类的组织
- 类应该短小
- 单一原则，只有一个理由去修改它
- 内聚
系统
复杂要人命，消磨开发者的生命，让产品难以规划、构建和测试
略
跌进
紧耦合的代码难以测试，所以运行所有的测试可以解耦
并发编程
略