代码整洁之道-第2章-有意义的命名-读书笔记

第 2 章 有意义的命名 15-28

2.1 介绍

　　文章列出取个好名字的几条简单规则。

2.2 名副其实

　　代码的模糊度：即上下文在代码中未被明确体现的程度。

2.3 避免误导

　　程序员必须避免留下掩藏代码本意的错误线索。应当避免使用与本意相悖的词。
　　提防使用不同之处较小的名称。
　　以同样的方式拼写出同样的概念才是信息。拼写前后不一致就是误导。

2.4 做有意义的区分

　　要区分名称，就要以读者能鉴别不同之处的方式来区分。

2.5 使用读得出来的名称

2.6 使用可搜索的名称

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

2.7 避免使用编码

2.7.1 匈牙利语标记法

　　匈牙利语标记法：Hungarian Notation,HN。
　　现在不需要这种标记法了。

2.7.2 成员前缀

　　也不必用 m_ 前缀来表明成员变量。应当把类和函数做得足够小，消除对成员前缀的需要。

2.7.3 接口与实现

2.8 避免思维映射

　　不应当让读者在脑中把你的名称翻译为他们熟知的名称。
　　聪明程序员和专业程序员之间的区别在于，专业程序员了解，明确是王道。专业程序员善用其能，编写其他人能理解的代码。

2.9 类名

　　类名和对象名应该是名词或名词短语。类名不应当是动词。

2.10 方法名

　　方法名应当是动词或动词短语。属性访问器、修改器和断言应该根据其值命名，并以 Javabean 标准加上 get 、 set 和 is 前缀。
　　重载构造器时，使用描述了参数的静态工厂方法名。

2.11 别扮可爱

2.12 每个概念对应一个词

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

2.13 别用双关语

　　避免将同一单词用于不同目的。同一术语用于不同概念，基本就是双关语了。如果遵循“一词一语”规则，可能在好多个类里面都会有 add 方法。只要这些 add 方法的参数列表和返回值在语义上等价，就一切顺利。

2.14 使用解决方案领域名称

　　记住，只有程序员才会读你的代码。所以，尽管用那些计算机科学（ Computer Science,CS ）术语、算法名、模式名、数学术语吧。依据问题所涉领域来命名可不算是聪明的做法，因为不该让协作者老师跑来跑去问客户每个名称的含义，其实他们早该通过另一个名称了解这个概念了。
　　程序员要做太多技术性工作。给这些事取个技术性的名称，通常是最靠谱的做法。

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

　　如果不能用程序员熟悉的术语来给手头的工作命名，就采用从所涉问题领域而来的名称吧。至少，负责维护代码的程序员就能去请教领域专家了。
　　优秀的程序员和设计师，其工作之一就是分离解决方案领域和问题领域的概念。与所涉问题领域更为贴近的代码。应当采用源自问题领域的名称。

2.16 添加有意义的语境

　　很少有名称是能自我说明的-多数都不能。反之，你需要用良好命名的类、函数或名称控件来放置名称，给读者提供语境。如果没这么做，给名称添加前缀就是最后一招了。
　　语境的增强也让算法能够通过分解为更小的函数而变得更为干净利落。

2.17 不要添加没用的语境

　　只要短命称足够清楚，就要比长命称好。别给名称添加不必要的语境。
　　对于 Address 类的实例来说， AccountAddress 和 customerAddress 都是不错的名称，不过用在类名上就不太好了。 Address 是个好类名。如果需要与 MAC 地址、端口地址和 Web 地址相区别，可以考虑使用 PostalAddress 、 MAC 和 UTL 。这样的名称更为精确，而精确正是吗，命名的要点。

2.18 最后的话

　　取好名字最难的地方在于需要良好的描述技巧和共有的文化背景。与其说这是一种技术、商业或管理问题，还不如说是一种教学问题。