《代码整洁之道 》第二章 有意义的命名

第二章 有意义的命名

名副其实

变量和方法的命名要有含义，有业务的含义。

这段代码，有什么目的？theList是什么？4又代表什么？

我们发现这个是一个扫雷的游戏。盘面是名为thelist的单元表格，数组的0下标是状态值，4标识已标记。 可以修改成这样：

还可以更进一步，数组表示的单元格，可以用一个类实现，写一个类函数 isFlagged，可以掩盖那个魔术数。

避免误导

比如accountList来指一组账号，除非他真的是List类型，不然List对程序员有特殊的意义，如果不是一个List，就会引起误导，所以使用accountGroup，bunchOfAccounts。

小写字母l 和大写字母O ，他们和数字 0 1 很像，也容易误导

有意义的区分

无意义的区分

public static void copyChars(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}

如果参数名改为source和destination，这个函数就会像样许多。” “废话是另一种没意义的区分。假设你有一个 Product 类。如果还有一个 ProductInfo 或ProductData类，那它们的名称虽然不同，意思却无区别。Info和Data就像a、an和the一样，是意义含混的废话。”

“getActiveAccount();

getActiveAccounts();

getActiveAccountInfo();

程序员怎么能知道该调用哪个函数呢？”

“如果缺少明确约定，变量 moneyAmount 就与 money 没区别，customerInfo 与 customer没区别，accountData与account没区别，theMessage也与message没区别。要区分名称，就要以读者能鉴别不同之处的方式来区分。”

使用读得出来的名称

使用可搜索的名称

找一个MAX_CLASSES_PER_STUDENT很容易，但是你想找一个一个数子 7 ，就麻烦了

虽然看起来拉长了代码，但是这些变量比数字好找多了。

避免使用编码

比如一些前缀,C标识细胞模块，C_ddd, C_yyy 人们很快就会学会无视前缀。

接口和实现

有时候写一些接口，IShapeFactory。或者CShapeFactory。就是个废话。我不想让用户知道我给他们的是接口

避免思维映射

不应当让读者在脑中把你的名称翻译为他们熟知的名称，这种问题经常出现在选择是使用问题领域术语还是解决方案领域术语时。

单个字母变量，当他的作用域很小的时候，没有冲突，是可以的，比如循环计数器，i，j。但是使用l O，就不行了

类名

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

避免使用Manager 、Processor 、Data或Info这样的动词。

方法名

方法名要应该是动词或者动词短语。postPayment 、deletePage 或save。属性访问器、修改器、断言应该根据其值命名，并依靠javaBean标准加上get、set、is前缀。

每个概念对应一个词

在同一堆代码中有controller，又有manager还有driver，就令人很困惑，DeviceManager和Protocol-Controller之间有和根本的区别?为什么不全用controller或managers，他们都是Drivers。

别用双关语

可能很多类里面都会有add方法，只要这些add方法的参数列表和返回值在语义上等价，就一切顺利。

但是有些人写add方法实现，该方法通过增加或连续两个现存值来获得新值。

比如 把单个参数放到群集（collection）中，这个方法还应该叫做add吗？

应该叫做insert或append这类才对。

使用解决方案领域名称

主要程序员才会读取你的代码，所以尽量使用计算机科学术语、算法名、模式名、数学术语。

对于熟悉访问者(VISITOR )模式的程序来说，名称AccountVisitor 富有意义。哪个程序员会不知道JobQueue 的意思呢？程序员要做太多技术性工作。给这些事取个技术性的名称，通常是最靠谱的做法。

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

如果不能使用程序员熟悉的术语来给手头的工作命名，就采用所涉问题领域而来的名称，至少这样，负责维护代码的程序员还可以去请教领域专家。

优秀的程序员，工作之一就是分离解决方案领域和问题领域的概念。与涉及问题领域更为贴近代码，应当采用源自问题领域的名称。

添加有意义的语境

设想你有名为firstName 、lastName street 、houseNumber 、city、state 和zipcode 的变量。 当它们搁一块儿的时候，很明确是构成了一个地址。不过，假使只是在某个方法中看见孤零零一个state 变量呢？你会理所当然推断那是某个地址的一部分吗？

有语境的代码

不要添加没用的语境

如果你有一个“豪华版加油站”(Gas Station Deluxe)的应用，在其中给每个类添加GSD前缀就不是什么好点子了。如果idea一搜索GSD就一堆。

再比如，你在GSD应用程序中的记账模块创建了一个表示邮件地址的类，然后给该类命名为GSDAccountAddress 稍后，你的客户联络应用中需要用到邮件地址，你会用 GSDAccountAddress 吗？这名字听起来没问题吗？在这17个字母里面，有10个字母纯属多 余和与当前语境毫无关联。

只要短名称足够清楚，就要比长名称好。

最后的话

取好名字最难的地方在于需要良好的描述技巧和共有文化背景。与其说这是一种技术、商业或管理问题，还不如说是一种教学问题。其结果是，这个领域内的许多人都没能学会做 得很好。