2.1 介绍

软件中随处可见命名。我们命名、命名，不断命名。既然有这么多命名要做，不妨做好它。

2.2 名副其实

名副其实说起来很简单。注意命名，而且一旦发现由更好的名称，就换掉旧的。

变量、函数或类的名称应该已经答复了所有的大问题。

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

选择体现本意的名称能让人更容易理解和修改代码。

2.3 避免误导

程序员必须避免留下掩盖代码本意的错误线索。应当避免使用与本意相悖的词。

提防使用外形相似度较高的名称。

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

误导性名称真正可怕的例子，是用小写字母l和大写字母O作为变量名，尤其是在组合使用的时候。

2.4 做有意义的区分

如果程序员只是为满足编译器或解释器的需要而写代码，就会制造麻烦。

以数字系列命名（a1、a2…aN）是依义命名的对立面。

废话时另一种没意义的区分。

废话都是冗余。

2.5 使用读得出来的名称

人类长于记忆和使用单词。

如果名称读不出来，讨论的时候就会像个傻鸟。

2.6 使用可搜索的名称

长名称胜于短名称，搜得到的名称胜于用自造编码代写就的名称。

窃以为单字母名称仅用于短方法中的本地变量。名称长度应与其作用域大小相对应。若变量或常量可能在代码中多处使用，则应赋予其便于搜索的名称。

2.7 避免使用编码

把类型或作用域编进名称里面，突然增加了解码的负担。

2.7.1 匈牙利语标记法

它们增加了修改变量、函数或类的名称或类型的难度，它们增加了阅读代码的难度，它们制造了让编码系统误导读者的可能性。

2.7.2 成员前缀

人们会很快学会无视前缀（或后缀），而只是看到名称中有意义的部分。代码读得越多，眼中就越没有前缀。最终，前缀变作了不入法眼的废料，变作了旧代码的标志物。

2.7.3 接口和实现

前导字母I被滥用到了说好听点是干扰，说难听点根本就是废话的程度。

2.8 避免思维映射

不应当让读者在脑中把你的名称翻译为他们熟知的名称。

聪明程序员和专业程序员之间的区别在于，专业程序员了解，明确是王道。专业程序员善用其能，编写其他人能理解的代码。

2.9 类名

类名和对象名应当是名词或名词短语。应避免使用Manager、Processor、Data或Info这样的类名。类名不应当是动词。

2.10 方法名

方法名应当是动词或动词短语，属性访问器、修改器和断言应该根据其值命名，并依Javabean标准加上前缀get、set和is。

重构构造器时，使用描述了参数的静态工厂方法名。

可以考虑将相应的构造器设置为private，强制使用这种命名手段。

2.11 别抖机灵

如果名称太耍宝，那就只有同作者一般有幽默感的人才能记住，而且还是在他们记得那个笑话的时候才行。

言到意到。意到言到。

2.12 每个概念对应一个词

给每个抽象概念选一个词，并且一以贯之。

2.13 别用双关语

避免将同一单词用于不同目的。

代码作者应尽力写出易于理解的代码。

2.14 使用解决方案领域名称

记住，只有程序员才会读你的代码。

程序员要做太多技术性工作，给这些事起个技术性的名称，通常是最靠谱的做法。

2.15 使用源自所涉问题领域的名称

如果不能使用程序员熟悉的术语来给手头的工作命名，就采用从所涉问题领域而来的名称吧。

2.16 添加有意义的语境

你需要用命名良好的类、函数或名称空间来放置名称，给读者提供语境。

2.17 不要添加没用的语境

只要短名称足够清楚，就比长名称好。别给名称添加不必要的语境。

精确正是命名的要点。

2.18 最后的话

起好名字最难的地方在于需要良好的描述技巧和共有文化背景。