《代码整洁之道》笔记 第二章
第二章 有意义的命名
2.1 名副其实
变量、函数或类的名称应该一眼看上去就能告知程序员它为什么存在、能做什么事、该怎么用。
2.2 避免误导
应该避免留下掩藏代码本意的错误线索。如
- 避免使用与本意相悖的词（
accountList可能会导致容器上的误判，accountGroup会更好） - 避免使用外形相似度较高的名称。
还需要当心0与O（字母O），1与l（小写L），I（大写i）作为变量名。在一些字体格式中很难区分。
2.3 做有意义的区分
坚持依义命名。使用数字或“废话”（Product与ProductInfo，a与the不应使用）区分毫无意义。若名称必须相异，则意思也应不同。
废话冗余。如table不应出现在表名中、variable不应出现在变量名中。
2.4 使用读的出来的名称
读不出来名称讨论时会很蠢。
2.5 使用可搜索的名称
单字母名称或数字常量因为大量出现导致很难搜索。长名称胜于短名称、可搜索的名称胜于自造的名称。名称长短应与其作用域大小相对应。
2.6 避免使用编码
将类型或作用域编进名称里，徒增负担、不宜发音也容易打错。
2.6.1 匈牙利标记法
匈牙利标记法（Hungarian Notation，HN）应减少使用或不再使用以减少阅读代码的难度。
2.6.2 成员前缀
不必使用m_前缀标明成员变量。应将类和函数做的足够小来消除对成员前缀的需要。
2.6.3 接口和实现
在接口和实现中必须选择一个来编码的话，选择实现如ShapeFactoryImp。
2.7 避免思维映射
不应让读者在脑中把名称翻译为他们熟知的名称。常出现在选择使用问题领域术语和解决方案领域术语。
减少使用单字母变量，哪怕是循环计数器i、j、k。
2.8 类名
类名与对象名应为名词或名词短语。如Customer、Account，避免使用Manager、Processor或Info。
2.9 方法名
方法名应为动词或动词短语。如postPayment、save属性访问器(accessor)、修改器(mutator)、断言(predicate)应根据其值命名，并依JavaBean标准加上前缀get、set、is。
重载构造器时，使用描述了参数的静态工厂方法名。如
1 | |
通常好于
1 | |
可以考虑将相应的构造器设置为private，强制使用该手段。
2.10 别抖机灵
名称别耍宝。
2.11 每个概念对应一个词
每个抽象概念选一个词，且一以贯之。如，用fetch、retrieve、get给在多个类中的同样方法命名。
2.12 别用双关语
避免将同一单词用于不同目的。
2.13 使用解决方案领域名称
计算机科学术语、算法名、模式名、数学术语均可以使用，因为只有程序员才会去读代码。
2.14 使用源自所涉问题领域的名称
无法用熟悉的术语命名，就是用所涉问题领域而来的名称。这样维护的程序员还可以去请教领域专家。
2.15 添加有意义的语境
可以给名称添加前缀来提供语境。
2.16 不要添加没用的语境
若短名称足够清楚，则无需添加不必要的语境。