清理代码也许只是改好一个变量名，拆分一个有点过长的函数，消除一点点重复代码，清理一个嵌套 if 语句。当梳理代码时，坚守此军规：每次 review 代码，让代码比你发现它时更整洁。
一、谨慎命名
给函数和变量取个好名字是优秀程序员的基本功，取名的基本要求是 名副其实，见文知意。如果名称需要注释来补充，那就不算是个好名字。
1 var d // 日期
修改为：
1 var date
取名的第二个要求是 避免误导。比如数据本身不是一个 list，那就别用 list 来命名，因为 list 一词对程序员有特殊的含义。
修改为：
取名的第三个要求是 去掉冗余。Variable一词永远不应当出现在变量名中，Table一词永远不应当出现在表名中。nameString 会比 name 好吗？ProductInfo 、 ProductData 和 Product 有什么区别？更糟糕的是，如果代码中同时存在 Article 和 ArticleInfo 类，程序员怎么知道该调用哪个类呢？多个意义含混的冗余词汇只会让阅读者困惑，要区分名称，就要以读者能鉴别不同之处的方式来区分。
例如：开始你用了 address 变量表示用户居住地，如上海、北京。后来又要求更详细地描述用户的居住地。如上海黄浦区、浦东区，北京海淀区、朝阳区。用什么来命名这个详细地址呢？detailAdress？smallAddress？还是 anotherAddress？这些统统都不是好的做法，牢记上述法则：以读者能鉴别不同之处的方式来区分，这时比较好的做法是修改之前的 address 变量名字为 city，再将区域的地址命名为 district。
取名的第四个要求是：严谨，不要俏皮。笔者曾经接手一位外国同事写的代码，在一个类中，这位外国同事使用了 wearClothes、wearPants 命名函数，之后又出现一个 startParty 函数。仔细理解后，笔者才发现，这是代表软件系统的第一步准备、第二步准备，然后正式启动这三个流程。或许这位同事写这个类时心情不错，将其比喻成了一个 party 的流程，但对于读者来说，梳理这三个函数的意思着实要费一番心思。事实上，此时我们最好将其命名为 firstStepOfPreparation、secondStepOfPreparation、systemBoot，宁可明确，毋为好玩。
二、函数和类
函数和类应该坚持 单一权责原则。保持高内聚，低耦合。隔离会让系统每个元素的理解变得容易。
单一权责原则：在面向对象编程领域中，单一权责原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。一个类或者模块应该有且只有一个改变的原因。
过长的函数会造成不易理解，如果某天这个函数需要修改的话，一个长长的函数会大大增加理解成本。并且，小函数也能更好地复用。
如果一个函数做了多件事，一个明显的标志是无法为它起一个精准的名字。你会觉得需要函数名需要使用 and 连接，比如 calculateAndPrintPrice，这时候最佳做法是将其拆分为 calculatePrice 和 printPrice 两个小函数。
函数的第二个规范是 尽量不要在参数中传递状态值，状态值是函数做了多件事的明显标志。例如：
修改为：
函数的第三个规范是 同一个函数中的代码应该属于同一层级。良好的软件设计要求分离位于不同层级的概念，较低层级概念和较高层级概念不应混杂在一起。
修改为：
三、坏注释与好注释
注释并不是越多越好，有的注释纯属无意义的废话，例如：
这些注释看起来就像是喃喃自语，或许读者阅读这些注释的时间比读代码还要长。好的注释只应该用在必要时，用于警告其他程序员会出现某种后果的注释是有用的，例如：
但，最好的注释是 没有注释，若代码足够有表达力，用代码来展示意图往往会更好。注释总是一种失败。当我们无法找到不用注释就能表达自我的方法时，我们写了注释，这并不值得庆贺。因为注释常常会撒谎。原因很简单：程序员不能坚持维护注释，尤其是别人写的注释。当另一个人修改了代码后，往往不会去阅读上一个人写的注释，再修改注释。所以注释常常会与其所描述的代码分割开来，孑然飘零，越来越不准确。
写注释的常见动机之一是原有代码混乱。当我们阅读代码时，发现已有的代码令人困扰、乱七八糟。这时我们也许会告诉自己：“等我阅读清楚后，给它写点注释！”别那样做！最好的做法是把代码整理干净。
修改为:
四、良好的格式
在我们阅读报纸时，在顶部，你期望有个头条，告诉你故事的主题。然后第一段是整个故事的大纲，给出粗线条概述，但隐藏了故事细节。接着读下去，细节渐次增加，直至你了解所有的细节。
代码的格式也要像新闻文章一样，最顶部给出高层次概念，向下渐次展开细节。函数应该紧跟调用处，保证垂直方向上的靠近。如果格式混乱，读者在阅读时总会滑上滑下，导致思维跳跃，增加不必要的理解难度。
影响格式的第二个要素是 缩进与间隔，现代化的 IDE 都有格式化代码快捷键，你也可以在设置中搜索"Reformat Code"，自定义格式化代码快捷键。随时格式化，并去掉多余的空行，让我们的代码保持清爽、整洁。
五、数据结构
在有的源代码中，作者采用长长的链式调用，甚至会鼓吹自己只写了一行代码便实现了此功能。事实上，绝不应该为了节省变量，写过长的链式调用，否则容易造成"火车失事"。正确的做法是遵守“得墨忒定律”：适当拆解链式调用，只和朋友谈话，不和朋友的朋友谈话，使得代码阅读和调试都更方便。
得墨忒定律（The Law of Demeter）：模块不应该了解它所操作对象的内部情形。
修改为：
六、错误处理
在处理程序异常时，我们常常会用到 try / catch 代码块，而 try / catch 代码块丑陋不堪，他们搞乱了代码结构，把错误处理与正常流程混为一谈。最好的做法是 把 try 和 catch 代码块的主体部分抽离出来，另外形成函数。错误处理就是一件事。
现代化的语言都有异常机制，异常情况如果不及时加以处理，可能会导致程序崩溃。所以有的程序员对于程序的异常情况会选择返回 0 或者 -1 等错误码，以保持程序不崩溃。
别这样做，正确的做法是将错误码替换为抛出异常，只有这样才能保证出现错误时立马就可以发现，而不是让程序在错误的状态下继续执行，将来造成更加迷惑的错误。
要讨论错误处理，就一定要提及那些容易引发错误的做法。第一项就是返回 null 值。我不想去计算曾经见过多少几乎每行代码都在检查 null 值的应用程序。返回 null 值基本上就是在给自己增加工作量，也是在给调用者添乱。只要有一处没有检查 null 值，应用程序就会失控。返回 null 不如抛出 NullPointerException ，或是替换为一个 空对象。让调用者不再需要检查 null，代码也就更整洁了。