第一、 可读性

并不是能运行就可以了，一定要有可读性。

第二、 格式

可以有自己的风格，但需要统一编程格式。

第三、 死代码

注释掉的代码块、未使用的变量和无法到达的代码都是垃圾-清理掉。

第四、 嵌套代码

虽然计算机很容易阅读这种代码，但对于人类则是非常大的精神负担。因此，代码会变得复杂、难以阅读。应该通过防御语句、提前返回或使用函数式编程等方式消灭嵌套代码。

第五、使用对象

长长的参数列表，杂乱的数据，自定义的数组或字典结构等。这些都可以重构成对象。这样不仅能让数据结构变得正规，还能容纳所有重复的、使用原始数据的重复的逻辑。

第六、大型代码块

虽然没有具体的数字，但代码块的长度应该是有限制的。如果你认为你的代码块过大，就应该对其进行识别、重组并重构。这个简单的过程可以让你确定代码块的上下文和抽象级别，以便正确地找出代码的任务，并将代码重构到更加易于阅读、更简单的代码块中。

第七、命名规则

当然，好的命名很困难，但只是因为我们人为增加了难度。有个小技巧在编程的许多方面都能用得上，包括命名，那就是——延后。不要纠结某个东西的命名，继续写代码就好。就算是用一整句话命名一个变量都没问题，继续写代码就好。我可以保证，当你完成整个功能之后，更好的名字就会浮出水面。

第八、删除注释

在我看来这一条至关重要，删了注释我才能把精力放到可读性上。不管我如何解释删除注释的必要性，总会有人跟我抬杠，然后举出一个绝对需要注释的例子。当然，如果哈勃望远镜要和古老的适配器连接，而后者返回一个意思不明的687，这种情况肯定需要注释来说明。但大多数其他情况下，你应该尽量重写代码使得它不需要注释也能看懂。

第九、合理的返回

我们总是选择返回最奇怪的值，特别是对于边界条件的情况。像-1、687或null。然后就得写很多代码来处理这些值。应该努力返回更有意义的值。理想情况下，最好是即使在反面情况下也能让调用者继续执行的值。如果真的是异常情况，那么最好用其他方式来通信，而不是使用null。

第十、三的原则

我们不应该太早做抽象。三的原则能阻止我们过早消除重复的努力，直到有了足够多的信息后再做出决定。用Sandi Mets的话说，“重复的代价远远低于错误的抽象。”

第十一、 对称性

代码中的对称性是说，同样的思想在任何地方都使用同样的实现。

cs