代码整洁之道 - 有意义的命名

1. 名副其实

好的命名会体现出它为什么会存在、它做什么事、应该怎么用。如果名称需要注释来补充，就不算名副其实。

int d; // 消逝的时间，以日统计

名称d没有体现出时间消逝的感觉，更体现不出“以日统计”。可以替换如下：

int elapsedTimeInDays;

int daysSinceCreation;

int daysSinceModification;

int fileAgeInDays;

再看下面的if判断：

if (status == 1) { … }

这里的数字1，无法看出它究竟代表什么意思，称为魔数。应该用有意义的名称代替。

if(status == FLAGGED) { … }

2. 避免误导

accountList代表一组账号，不过它真的是List类型吗？如果不是请修改为accountGroup，否则会引起误导。即便真的是List类型，最好也别在名称中写出容器类型名。

不要在同一“地点”使用在“外形”上难以区分的两个名称，如XYZControllerForEffcientHandlingOfStrings和XYZControllerForEfficientStorageOfStrings。

慎用小写字母l、大写字母O作为变量名。它们与数字1和0太相似了。

3. 做有意义的区分

void copyChars(char a1[], char a2[]) {…}

void copyChars(char source[], char destination[]) {…}

显然source、destination比a1、a2像样多了，这就是有意义的区分。不要做无意义的区分，ProductInfo或ProductData里面的Info和Data就是意义含混的废话，还不如直接用Product。废话都是冗余，要区分名称，就要以读者能鉴别出不同之处的方式来区分。

4. 使用读的出来的名称

Date genymdhms;

genymdhms是什么意思？能读的出是“生成日期，年、月、日、时、分、秒”吗？读不出来的话，还是换成generationTimestamp（生成时间戳）更好点。

5. 使用可搜索的名称

单字母名称和数字常量很难在一大篇文字中找出来，试想一下在整个工程源码中想通过搜索变量e来了解它的来龙去脉会是什么情况。一般单字母名称仅用于短方法中的本地变量或者循环计数器。

6. 避免使用“编码规则”

使用“编码规则”是自找麻烦，徒增了解代码的负担（还要再搞懂这种编码“语言”）。

匈牙利标记法（Hungarian Notation）只在早期的Windows C API时期尤为重要，因为那时的编译器并不做类型检查，程序员需要借助匈牙利标记法来区别不同类型。

不必用m_前缀来表明类的成员变量。我们应该只看到名称中有意义的部分，前缀是不入法眼的废料，它是旧代码的标志物。

7. 类名和方法名

类名和对象名应该是名词或名词短语，如Customer、WikiPage、Account、AddressParser。类名不应该是动词。

方法名应该是动词或动词短语。如postPayment、deletePage、save。

属性访问器、修改器和断言应该根据其值命名，并加上get、set、is前缀。例如getName、setName、isPosted。

8. 每一个概念对应一个词

给每一个抽象概念选一个词，并且一直使用。不要混用fetch、retrieve、get这些意思相近的词。例如controller、manager，最好选择其中一个，并一直使用。

9. 别用双关语

避免将同一单词用于不同目的或者不同概念。例如add如果表示将通过增加或者连接两个现存值来获得新值，那么当表达将一个参数放到集群（collection）中这个意思时就不应该再用add，可以改用insert。

10. 添加有意义的语境

假设firstName、lastName、street、houseNumber、city、state这些变量放在一起，则很明确的构成了一个地址。但如果只看见孤零零的state呢？你会理所当然的推断它是某个地址的一部分吗？这时最好添加前缀（如addrState），以此提供语境。必要的时候应该将这些变量和其相应的方法封装到一个类里面以增强语境。

11. 不要添加没用的语境

比如一个名为“Gas Station Deluxe（加油站豪华版）”的应用，给其中每个类都添加GSD前缀，例如GSDAccountAddress，这个GSD纯属多余，与当前语境毫无关联。

12. 最后的话

如果你在维护别人写的代码，或者自己旧代码，不妨试试上面这些规则，使用重构工具解决问题。效果会立竿见影，而且会持续下去。

【学习资料】 《代码整洁之道》