《修改代码的艺术》一书作者对整洁代码的描述：我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的，整洁的代码总是看起来像某种特别在意他的人写的，几乎没有改进的余地，代码的作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给的代码——全心投入某人留给你的代码。
这本书关于函数的介绍和其他架构书差不多，主要就是两个点：1. 短小，2. 抽象层次一致性。
毫无疑问，注释是代码中的坏味道。
对于一部分注释，我们可以使用类似 4.4.8 这种变量的方式，通过新增两个变量，来解释我们的内容。
那种生成的注释和我们注释掉的代码，我的建议是：不要留。
相关函数：按照本书的说明，若某个函数调用了另外一个，就应该把它们放到一起，而且调用者应该尽可能放在被调用者上面。我自己之前的习惯是调用者在被调用者的下面，目前又思考了一下，像作者这样组织，可能可读性反而更高。
因为这样设计可以像报纸一样，最重要的概念先出现，并且希望以包括最小的细节表述他们，期望底层的细节后出现。
使用异常而非返回码： 在 《代码精进之路》的读书笔记中，也提及了类似的思路，这个书里面又提到了使用异常而非返回码这一点，并且给出了一个新的理由，返回码意味着我们需要立即处理，这个步骤可能很容易被遗忘，而且会让我们的代码变得比较乱。
关于返回 null 值：有的时候，我们在数据处理中出现问题，可能会返回一个 null 或者 undefined。但是我建议相对于此，我们更应该直接抛出异常，返回 null 值意味着依赖调用者来做空检查，而且你不知道这个 null 究竟什么时候才会引发错误，这样会有较高的不稳定性。
对于类的组织中，属性顺序的一个建议：依次是公共静态常量、私有静态变量、公共函数、私有函数。
类的权责：对于一个类来说，我们不希望它被定义的太长，当然这个不能单纯地使用代码行数来判断，我们应该使用类的权责来判断，当一个类的名称越含糊，该类越有可能拥有更多权责，比如它的名称包含了诸如 Processor、Manager 或 Super，那么这种现象往往说明有不恰当的权责聚集的情况出现。
如何把类拆的短小：我给出一个切实可行的办法，可以先从类的复杂函数入手，我们在把函数拆分的过程中，发现某些部分拆分成函数之后会传递大量的参数给它，否则很难拆分，那么传递给它这个函数的参数就可以被整合进新的小类的实体变量，这样我们就无需传递参数，同时也完成了拆分。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。