Naming

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

命名非常重要。不论是变量常量，还是方法对象，一旦确定名称，代码的整体风格就开始受到影响，并且会一直持续下去。

书里介绍的各种技巧，大致都基于信息量和准确性两点。前者可以保证名称足够有意义，同时也检验了其存在的必要性；而后者能够减少代码中的重复定义，还有助于加速 debug 的推导过程。

另外，单词量有时也会影响命名能力。比如 make，作为动词来描述一个操作可能并不够清晰，更好的选择还有 create/generate/setup/compose 等。如果不认识这些单词，就想不到更多更合适的名称。

Comment

给代码加注释是一件很有争议的事情，因此作者也提到：要明确什么时候需要，什么时候不需要。好的代码如同好的文章，自成一体，但这不代表注释就是无意义的。

广义上讲，注释也是另一种形式的文档。单行注释、方法的注解和模块的说明，对于不想了解实现细节的人来说，比代码本身更有价值。

在工作中，写文档的时间并不比编码少。两者并不冲突，因为归根到底都是要把一件事情描述清楚，一个给人看，另一个给机器。文档写得清晰，写代码也会轻松。从使用者的角度看，对于开源项目，我们对文档的关注度更高，在使用中大部分时间都是在查阅手册，而非源代码。

在 Python 中写出好看的 Oneliner 很容易，但后果可能是灾难性的，会给代码的修改和调试过程带来意想不到的困难。Debug 时往往需要快速定位问题，如果遇到过于压缩的语句，便很难在短时间内拆解逻辑，更不用说再做修改，此时的代码就像个花瓶，精致而易碎。

Less is more。不考虑可读性的话，代码越少，带来的麻烦反而会越多。

书里还说把想法变成代码，关键在于是否能把程序要做的事情用自然语言解释清楚。

这和写文章何其相似：命题，描述中心思想，行文通顺，言之有物。如果是写一个函数，那就变成：抽象接口，梳理逻辑，解耦并拆分子任务。

随着时间发展，还要给内容做适当的减法。比如抽取重复的代码逻辑，OOP，用第三方库代替现有功能。对于文章来说则是，删除废话，同样的描述语只保留一个，使用更精简的词汇表达等等。

把编码当成写作，是这件事最吸引我的地方。前者不只是枯燥的堆砌，后者也并非涂鸦般简单，在 Art of readability 这一点上，它们是相通的。