第二章 命名的意义

2.2 名副其实

• 当发现更为合适的名称时，及时换掉旧名称；
• 变量名称应当解释其为何存在，如何使用，当需要注释时，不能称为名副其实
• 对于变量的命名，开头的单词小写，之后的单词首字母大写；
• 当一段简洁的代码不能解释其具体功能时，问题是其模糊度出现问题，即上下文含义不能再代码中体现出来；

2.3 避免误导

• 名称中不要出现误导词，例如一些具有特定含义的缩写，或者计算机科学中特定的名称；（需要解释）
• 不要使用型似的两个单词，辨别需要花费时间；
• 当一个类中方法名称具有较大的差异时，IDE中选择方法时时间较快，不需要较多的选择；

2.4 做有意义的区分

• 不要为了骗过编译器而随意起变量名称；例如相同的两个变量名称，给其中一个添加数字或者故意修改为错误单词；
• 在变量名称中不要说废话，Product和ProductInfo是同一个意思，没有区分度；
• 不要使用冗余的废话，variable不要出现在变量名称中，table不出现在表中；

2.5 使用读的出来的名称

• 名称应当能够使用自然语言读出，具有一定的含义；

2.6 使用可搜索的名称

• 单个字母或者数字在工程中大量存在，不易搜索；

2.7 避免使用编码

• 在如今的IDE环境中不需要使用编码去记住变量的某些特定含义；
• 不必使用m_前缀表明成员变量；应当把类和函数做的足够小，无需区分；

2.8 避免思维映射

• 变量名称应当具有清晰的意思，而不是各自的理解；

2.9 类名

• 类名和变量应当是名词或者名词短语；
• 避免使用Manager、Processor、Data、Info；

2.10 方法名

• 应当是动词或者动词短语；
• 属性的访问、修改和断言，应当使用其值命名并且加上set、get和is前缀；
• 重载构造函数时，使用参数描述的静态类方法；将通用的构造方法设为私有

Complex fulcrumPoint = Complex.FromRealNumber(23.0); //优于下一种方法
Complex fulcrumPoint = new Complex(23.0);

2.11 别办可爱

• 名称不应使用俚语或者与文化背景相关的语言；

2.12 每个概念对应一个词

• 方法名称应当对于无二，即使操作类型相同，不同的类中也应当不同（IDE可以避免这种问题，对象对应的方法有列出）；
• 同一意思应当只使用同一名称，一以贯之；例如controller和manager为相同的意思，不应同时使用；

2.13 别用双关语

• 同一单词不应有不同意思

2.14 使用解决方案领域的名称

• 代码只有程序员阅读，所以可以大量使用计算机科学的知识

2.15 使用问题领域的名称

• 当不能适应解决方案领域的名称时，使用问题领域的名称；
• 应当分离解决方案领域和问题领域的概念；
• 当所涉领域更为贴近代码时，使用该领域名称；

2.16 添加有意义的语境

• 代码的上下文应当构成一定的语境，帮助理解；
• 当不能构成语境时，可以添加合适的前缀，帮助理解；

2.17 不添加无用的语境

• 只要短名称足够清楚，就比长名称好；例如将应用名称添加到所以类的名称中时不够明智的；
• 命名要精确，Address没有ProtocolAddress、MAC和URI好；