代码整洁之道(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. 大师级程序员把系统当作故事来讲,而不是当作程序来写

类别: ReadingNotes. 标签: . 阅读(147). 订阅评论. TrackBack.

Leave a Reply

4 Comments on "代码整洁之道(Clean Code) 笔记(一)"

avatar
mashiguang
Guest
mashiguang

说函数尽量短小没有错,但说函数不能超过20行就有点不讲理了;
说缩进层级尽量少没有错,但说层级不能多于两层也太霸道了;
这些量化的东西要是写进代码规范里,代码没法写了。

一直没有看这本书,既然是行业畅销书,一定有它的价值,但真心不喜欢里面的这些量化的规范,太八股了。