第四章：注释
- 别给糟糕的代码加注释 -- 重新写吧
- 什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧，提供错误信息的注释更有破坏性
- 若编程语方足够有表达力，或者我们长于用这些语方来表达意图，就不那么需要注释 -- 也许根本不需要
- 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败
- 不准确的注释要比没注释坏得多。它们满口胡言。代码，只有代码能忠实的告诉你它做的事
- 好注释不多，如法律信息，警示等。我都不觉得
TODO是多好的东西 - 大多数注释都是坏注释，甚至一些 IDE 自动生成的代码也加一堆的废话注释，分散阅读注意力。我也写过那种日志式注释，这本是版本控制系统干的事。
- 很奇怪 IntelliJ IDEA 还在自动为新建的类加下创建者，代码是团队共有，时间长了根本就与作者无半毛关系。我经常碰到这种写有作者的代码哭笑不得，直接把原作者改了或删了也不太好，还不如把文件删了，新建一个没有作者注释的类
- 直接把代码注释掉是种讨厌的做法，自己可能不会再启用，其他人以为很重要更不敢删。不用了最好果断删掉，版本控制系统会帮你记住历史。
- 个人认为，注释会胡说八道，产品代码和测试代码不会撒谎。有功夫写注释还不如写好测试用例，测试需要维护，它本身就是最真实的文档。
第一章：整洁代码
- 代码即设计
- 童子军军规：把露营地清理得比来时还干净，签入代码前是否已做重构
- 你湎自行实践，且体验自己失败。你须观察他人的实践与失败
- 勒布朗(LeBlanc) 法则：稍后等于永不 (Later equals never)
- 赶上期限的唯一方法--做得快的唯一方法--就是始终尽可能保持代码整洁
- 缺乏“代码感”的程序员，看混乱是混乱，无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化
- 不好的代码引诱别人做没规矩的优化，搞出一堆混乱来
- 整洁的代码只做好一件事，糟糕的代码想做太多事，它意图混乱，目的含混
- 整洁的代码从不隐藏设计者的意图
- 整洁的代码只提供一种而非多种做一件事的途径
- 整洁的代码总是看起来像是某位特别在意它的人写的
- 回放我们编码过程显示，多多数时间都是在滚动屏幕，浏览其他模块
- 读与写花费时间的比例超过 10:1, 写新代码时，我们一直在读旧代码
- 编写代码的难度，取决于读周边代码的难度