Question

在给变量、函数或者其他元素命名时，要把它描述得更具体而不是更抽象。

例如，假设你有一个内部方法叫做ServerCanStart()，它检测服务是否可以监听某个给定的TCP/IP端口。然而ServerCanStart()有点抽象。CanListenOnPort()就更具体一些。这个名字直接地描述了这个方法要做什么事情。

下面的两个例子更深入地描绘了这个概念。

例子：DISALLOW_EVIL_CONSTRUCTORS

这个例子来自Google的代码库。在C++里，如果你不为类定义拷贝构造函数或者赋值操作符，那就会有一个默认的。尽管这很方便，这些方法很容易导致内存泄漏以及其他灾难，因为它们在你可能想不到的“幕后”地方运行。

所以，Google有个便利的方法来禁止这些“邪恶”的建构函数，就是用这个宏：

这个宏定义成：

通过把这个宏放在类的私有部分中，这两个方法^[1]成为私有的，所以不能用它们，即使意料之外的使用也是不可能的。

然而DISALLOW_EVIL_CONSTRUCTORS这个名字并不是很好。对于“邪恶”这个词的使用包含了对于一个有争议话题过于强烈的立场。更重要的是，这个宏到底禁止了什么这一点是不清楚的。它禁止了operator=（）方法，但这个方法甚至根本就不是构造函数！

这个名字使用了几年，但最终换成了一个不那么嚣张而且更具体的名字：

[1]指拷贝构造函数和赋值操作符。

例子：——run_locally（本地运行）

我们的一个程序有个可选的命令行标志叫做——run_locally。这个标志会使得这个程序输出额外的调试信息，但是会运行得更慢。这个标志一般用于在本地机器上测试，例如在笔记本电脑上。但是当这个程序运行在远程服务器上时，性能是很重要的，因此不会使用这个标志。

你能看出来为什么会有——run_locally这个名字，但是它有几个问题：

·团队里的新成员不知道它到底是做什么的，可能在本地运行时使用它（想象一下），但不明白为什么需要它。

·偶尔，我们在远程运行这个程序时也要输出调试信息。向一个运行在远端的程序传递——run_locally看上去很滑稽，而且很让人迷惑。

·有时我们可能要在本地运行性能测试，这时我们不想让日志把它拖慢，所以我们不会使用——run_locally。

这里的问题是——run_locally是由它所使用的典型环境而得名。用像——extra_logging这样的名字来代换可能会更直接明了。

但是如果——run_locally需要做比额外日志更多的事情怎么办？例如，假设它需要建立和使用一个特殊的本地数据库。现在——run_locally看上去更吸引人了，因为它可以同时控制这两种情况。

但这样用的话就变成了因为一个名字含糊婉转而需要选择它，这可能不是一个好主意。更好的办法是再创建一个标志叫——use_local_database。尽管你现在要用两个标志，但这两个标志非常明确，不会混淆两个正交的含义，并且你可明确地选择一个。