代码整洁之道 第 2 章 有意义的命名
摘自《代码整洁之道》第 2 章
（第 1 章的内容）写新代码时我们一直在读旧代码，多数时间都在读。编写代码的难易程度取决于读周边代码的难度。
2.2 名副其实
一旦发现有好的名称就换掉旧的
需要注释的名称不算名副其实。
- 反思：代码里注释是否过多，能否通过好的命名来减少注释量？
2.3 避免误导
避免留下掩藏代码本意的错误线索。避免使用与本意相悖的词。
- 例如，变量命名含 list 会让人认为这个变量是 list 类型的
提防使用差异较小的名称
XYZControllerForEfficientHandlingOfString与XYZControllerForEfficientStrorageOfString差异太小，为了区分它们需要花费不少时间。
2.4 做有意义的区分
名称虽然不同的，但意义如果没区别，则只是废话。
- Info 与 Data，a 与 the，表名中的 table，NameString 的 String，moneyAmount 与 Money……
2.5 使用读得出来的名称
便于记忆也便于交流
2.6 使用可搜索的名称
避免使用容易混在大量文本中导致难以通过搜索定位的名称。
长名称胜于短名称，搜得到的名称胜于用自造编码代写就的名称。
2.7 避免使用编码
把类型或作用域编进名称里面，徒然增加了解码的负担。
2.8 避免思维映射
不要用只有自己才懂得含义的名称。
2.9 类名
类名和对象名应该是名词或名词短语。
2.10 方法名
方法名应当是动词或动词短语。
2.11 别扮可爱
名称别耍宝
2.12 每个概念对应一个词
同一概念使用相同的词表示，不要同时用多个词给同种方法命名。
- 例如：fetch、retrieve、get；controller、manager、driver
2.13 别用双关语
避免将同一单词用于表示不同的概念。
2.14 使用解决方案领域名称
只有程序员才读你的代码，因此尽管使用 CS 领域的术语，这是程序员熟悉的。
2.15 使用源自所涉问题领域的名称
无法用程序员熟悉的术语来命名时，使用所涉问题领域的名称，这样至少维护代码的程序员可以请教领域专家。
分离解决方案与问题领域的概念，与所涉问题领域更为贴近的代码，应当采用源自问题领域的名称。
2.16 添加有意义的语境
用良好的类名、函数或命名空间来放置名称，给读者提供语境。
2.17 不要添加没用的语境
只要短名称足够清楚，就要比长名称好。
- 反例：某模块的名称全部带上了一个多余的前缀、名称中跟当前语境毫无关联的短语。