代码整洁之道(Clean Code) 笔记(一)

第一章：整洁代码

1. 代码即设计
2. 童子军军规：把露营地清理得比来时还干净，签入代码前是否已做重构
3. 你湎自行实践，且体验自己失败。你须观察他人的实践与失败
4. 勒布朗(LeBlanc) 法则：稍后等于永不 (Later equals never)
5. 赶上期限的唯一方法--做得快的唯一方法--就是始终尽可能保持代码整洁
6. 缺乏“代码感”的程序员，看混乱是混乱，无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化
7. 不好的代码引诱别人做没规矩的优化，搞出一堆混乱来
8. 整洁的代码只做好一件事，糟糕的代码想做太多事，它意图混乱，目的含混
9. 整洁的代码从不隐藏设计者的意图
10. 整洁的代码只提供一种而非多种做一件事的途径
11. 整洁的代码总是看起来像是某位特别在意它的人写的
12. 回放我们编码过程显示，多多数时间都是在滚动屏幕，浏览其他模块
13. 读与写花费时间的比例超过 10:1, 写新代码时，我们一直在读旧代码
14. 编写代码的难度，取决于读周边代码的难度

第二章：有意义的命名

1. 一旦发现有更好的名称，就换掉旧的; 如果名称需要注释来补充，那就不算是名副其实
2. 好名称要能读得出来，像 genymdhms 给人解释时就没法读，generationTimestamp 就不一样的
3. 名称长长短应与其作用域大小相对应，以便于搜索
4. 工厂方法通常好于构造函数，如 Complex.fromRealNumber(23.0) 优于 new Complex(23.0), 因为方法名派上用场了
5. 只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境，如 accountAddress, customerAddress

第三章：函数

1. 函数的最基本规则是要短小，20 行，不能再多了。现在的 Lambda(相当于一个匿名函数) 也不要超过 20 行
2. 函数应该做一件事。做好这件事。只做这一件事
3. 函数内的缩进层级不该多于两层
4. switch 语句很容易让函数做多件事，所以有个规矩是如果 switch 语句只出现一次，用它来创建多态对象 
5. 函数越短小，功能越集中，就越便于取个好名字。函数名长点没关系，总比额外的描述性注释好
6. 函数参数像缩进层级一样，尽量要少，零个，一个，二个，最好不要超过两个了。参数越多测试的组合就复杂了
7. 标识参数丑陋不堪。向函数传入布尔值简直就是骇人听闻的做法。直接是在宣布本函数不止做一件事。何不声明为两个方法，用方法名标识用意
8. 有多少人搞不清楚 assertEquqls(expected, actual) 两个参数分别是什么，反正这个反了好像也没关系，有些时候先后却很重要
9. 不要在无副作用方法名的掩盖下干着有副作用的事情，例如 getXxx(), checkXxx() 中把某个文件删了就很奇怪
10. 函数要么做什么，要么回答什么事，二者不可兼得，像 if(set("username", "unclebob"))... 就令人费解了
11. 使用异常替代返回错误码。我倾向于抛异常，而不喜欢在返回值中搞，像 if(deletePage(page) == E_OK) 或 Either(Error, Result) 都觉得不好接受
12. 错误状态枚举的扩展不如创建新的异常派生类方便
13. 可能并不是从一开始就写出好的函数。刚开始时可能并未遵从任何上面的规则，但加上测试后便可以随心所欲的重构来应用上面的规则
14. 大师级程序员把系统当作故事来讲，而不是当作程序来写