1.注释篇
Any comment that forces you to look in another module for the meaning of that comment has failed to communicate
to you and is not worth the bits it consumes.
任何迫使读者查看其他模块的注释，都没能与读者沟通好，不值所费。
If authors aren't paying attention when comments are written(or pasted), why should readers be expected to profit from them?
如果作者在写注释时都没花心思，怎么能指望读者从中获益呢？
2.格式篇
Unfortunately, most tools for reformatting code are blind to the precedence of operators and impose the same spacing throughout. So subtle spacings like those shown above tend to get lost after you reformat the code.
不幸的是，多数代码格式化工具都会漠视运算符优先级，从头到尾采用同样的空格方式。在重新格式化代码后，以上这些微妙的空格用法就消失殆尽了。
注：微妙的空格用法指高优先级运算符和操作数之间不用空格，而低优先级运算符则可以添加空格。
3.函数与数据结构篇
The Law of Demeter:
- Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
相关阐述：http://www.importnew.com/10501.html
4.错误处理篇
We can write robust clean code if we see error handling as a separate concern, something that is viewable independently of our main logic.
如果将错误处理隔离看待，隔离于主要逻辑之外，就能写出强固而整洁的代码。
5.单元测试篇
Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.
测试代码和生产代码一样重要。它可不是二等公民。它需要被思考、被设计和被照料。它必须像生产代码一般保持整洁。
6.类篇
The Single Responsibility Principle (SRP)2 states that a class or module should have one, and only one, reason to change.
Classes should have one responsibility—one reason to change.
单一权责原则认为，类或模块应有且只有一条加以修改的理由。
类只应有一个权责——只有一条修改的理由。
7.迭进
Once we have tests, we are empowered to keep our code and classes clean. We do this by incrementally refactoring the code. For each few lines of code we add, we
pause and reflect on the new design. Did we just degrade it? If so, we clean it up and run our tests to demon- strate that we haven’t broken anything. The fact that
we have these tests eliminates the fear that cleaning up the code will break it!
有了测试，就能保持代码和类的整洁，方法就是递增式地重构代码。对于我们添加的每几行代码，我们就要停顿下来并思考新的设计。设计退步了吗？如果是，就要清理它，并且运行测试以
保证没有破坏任何东西。测试消除了对清理代码就会破坏代码的恐惧。
8.并发编程篇
The synchronized keyword introduces a lock. All sections of code guarded by the same lock are guaranteed to have only one thread executing through them at any
given time. Locks are expensive because they create delays and add overhead. So we don’t want to litter our code with synchronized statements. On the other hand,
critical sec- tions13 must be guarded. So we want to design our code with as few critical sections as possible.
java关键字synchronized制造了锁。同一个锁维护的所有代码区域在任一时刻保证只有一个线程执行。琐是昂贵的，因为它们带来了延迟和额外开销。所以我们不愿意将代码扔给synchronized
语句了事。另一方面，临界区应该被保护起来。所以，应该尽可能少地设计临界区。
This just reinforced the fact that different operating systems have different threading policies, each of which impacts the code’s execution. Multithreaded code behaves
differently in different environments.16 You should run your tests in every potential deployment environment.
这正强调了不同操作系统有着不同线程策略的事实，不太的线程策略影响了代码的执行。在不同环境中，多线程代码的行为也不一样。应该在所有可能部署的环境中运行测试。
9.逐步改进篇-successive refinement
10.味道与启发篇
A more subtle form is the switch/case or if/else chain that appears again and again in various modules, always testing for the same set of conditions. These should be replaced with polymorphism.
Still more subtle are the modules that have similar algorithms, but that don’t share similar lines of code. This is still duplication and should be addressed by using the TEM- PLATE METHOD,4 or STRATEGY5 pattern.
（关于重复）较隐蔽的形式是在不同模块中不断重复出现、检测同一组条件的switch/case或if/else链。可以用多态来代替之。
更隐蔽的形态是采用类似算法但具体代码行不同的模块。这也是一种重复，可以使用模板方法模式或策略模式来修正。