本文与大家聊一聊编程中非常关键的一个点，如何更好的对代码命名。

《代码整洁之道》这本书提出了一个观点：代码质量与其整洁度成正比，干净的代码，既在质量上可靠，也为后期维护、升级奠定了良好基础。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。

但我们知道，很多时候，理想很丰满，现实很骨感，也知道人在江湖，身不由己。因为项目的紧迫性，需求的多样性，我们无法时时刻刻都写出整洁的代码，保持自己输出的都是高质量、优雅的代码。

但若我们理解了代码整洁之道的精髓，我们会知道怎样让自己的代码更加优雅、整洁、易读、易扩展，知道真正整洁的代码应该是怎么样的，也许就会渐渐养成持续输出整洁代码的习惯。

而且或许你会发现，若你一直保持输出整洁代码的习惯，长期来看，会让你的整体效率和代码质量大大提升。

先放出这篇文章所涉及内容知识点的一张思维导图，就开始正文。大家若是疲于阅读文章正文，直接看这张图，也是可以Get到本文的主要知识点的大概。

名副其实说起来貌似很简单，但真正做起来，似乎没那么容易。选个好名字要花一些时间，但其实选好名字之后省下来的时间，要比之前选名字时花掉的时间多得多。

我们一旦发现有更好的名称时，就应该换掉之前的旧名称，这样做读你代码的人（包括你自己），都会很开心。

一个好的变量、函数或类的名称应该已经几乎答复了所有的大问题。它应该告诉你，这个名称所代表的内容，为什么会存在，做了什么事情，应该如何用等。

如果一个名称需要注释来补充才能让大家明白其真正含义，那其实就不算是名副其实。（并不是说不需要注释，恰如其分的注释是程序员让自己代码锦上添花的好方法，关于注释的一些注意事项，稍后会有文章专门涉及。）

举个栗子：

以下的这句代码里的d就不算是个好命名。名称d什么都没说，它没引起我们对时间消逝的感觉，更别说单位是天了：

我们应该选择这样的指明了计量对象和计量单位的名称：

我们应该避免留下隐藏代码本意的错误线索，也应该避免使用与本意相悖的词。例如，别用accountList来指一组账号，除非它真的是List类型，用accountGroup、bunchOfAccounts，或者直接用accounts，都是更好的选择。

尽量提防长得太像的名称。想区分XYZControllerForEfficientHandlingOfStrings和XYZControllerForEfficientStorageOfStrings，会花费我们太多的时间。因为这两个词，实在太相似了。

 以同样的方式拼写出同样的概念才是信息，拼写前后不一致就是误导。

        1.尽量避免使用数字系列命名（a1、a2…….aN）。这样的名称纯属误导，因为很多时候完全没有提供正确的信息，没有提供导向作者意图的线索。

        2.废话是另一种没有意义的区分。如果我们有一个Product类，还有一个ProductInfo或ProductData类，那么他们的名称虽然不同，但意思却无区别。这里的Info、Data就像a、an和the一样，是意义含混的废话。

        注意，只要体现出有意义的区分，使用a、the这样的前缀就没错。例如，将a用在域内变量，把the用于函数参数。

我们要使用读得出来的名称。如果名称读不出来，讨论的时候就会不方便且很尴尬，甚至让旁人觉得很蠢。

例如，变量名称是beeceearrthreecee，讨论的时候读起来简直像没吃药。

单字母和数字常量有个问题，就是很难再一大篇文字中找出来。

找MAX_CLASSED_PER_STUDENT很容易，但想找数字7，就很麻烦。

同样，字母e也不是个便于搜索的好变量名。因为作为英文中最常用的字母，在每个程序、每段代码中都有可能出现。

 名称长短应与其作用域大小相对应，若变量或常量可能在代码中多处使用，应赋予其以便于搜索的名称。

举个栗子，比较如下两段代码：