违反语法规则的命名

CR一段代码：

public void completedTranslate(final List<ChapterId> chapterIds) {
  List<Chapter> chapters = repository.findByChapterIdIn(chapterIds);
  chapters.forEach(Chapter::completedTranslate);
  repository.saveAll(chapters); 
}

乍看写得还不错，将一些章节信息标记为翻译完成。似乎方法名也能表达这意思，但经不起推敲。

completedTranslate 并不是一个正常的英语方法名。从这个名字你能看出，作者想表达的是“完成翻译”，因为已经翻译完了，所以用完成时的 completed，而翻译是 translate。这个函数名就成了 completedTranslate。

一般命名规则是：

• 类名是个名词
  表示一个对象
• 方法名是个动词或动宾短语
  表示一个动作

以此为标准判断，completedTranslate 并不是一个有效的动宾结构。如果把这个名字改成动宾结构，只要把“完成”译为 complete，“翻译”用成它的名词形式 translation 就可以了。所以，这个函数名可以改成 completeTranslation：

public void completeTranslation(final List<ChapterId> chapterIds) {
  ...
}

这并不是个复杂的坏味道，但却随处可见。

比如，一个函数名是 retranslation，其表达的意图是重新翻译，但作为函数名，它应该是一个动词，所以，正确的命名应该是 retranslate。

只要你懂得最基本的命名要求，知道最基本的英语规则，就完全能够发现这类坏味道。

不准确的英语词汇

有一次，我们要实现一个章节审核的功能，一个同事先定义出了审核的状态：

public enum ChapterAuditStatus {
    PENDING,
    APPROVED,
    REJECTED;
}

有问题吗？看不出来，一点都不奇怪。如果你用审核作为关键字去字典网站上搜索，确实会得到 audit 这个词。所以，审核状态写成 AuditStatus 太正常了。

然而，看到这个词的时候，我的第一反应就是这个词好像不太对。因为之前我实现了一个作品审核的功能，不过我写的定义是这样的：

/

public enum BookReviewStatus {
    PENDING,
    APPROVED,
    REJECTED;
}

抛开前缀不看，同样是审核，一个用 audit，一个用 review。本着代码一致性，希望这两个定义采用同样词汇。

搜索引擎里查下。原来，audit 有更官方的味道，更合适的翻译应该是审计，而 review 则有更多核查的意思，二者相比，review 更适合这里的场景。于是，章节的审核状态也统一使用了 review：

public enum ChapterReviewStatus {
    PENDING,
    APPROVED,
    REJECTED;
}

这个坏味道就是个高级的坏味道，英语单词用得不准确。

但这个问题确实是国内程序员不得不面对的一个尴尬的问题，英语没那么好，体会不到不同单词之间差异。

很多人就是把中文扔到 Google 翻译，然后从诸多返回的结果中找一个自己看着顺眼的，而这也往往是很多问题出现的根源。这样写出来的程序看起来就像一个不熟练的外国人在说中文，虽然你知道他在说的意思，但总觉得哪里怪怪的。

最好的解决方案还是建立业务词汇表。一般情况下，我们都可以去和业务方谈，共同确定一个词汇表，包含业务术语的中英文表达。这样在写代码的时候，你就可以参考这个词汇表给变量和函数命名。

下面是一个词汇表的示例，从这个词汇表中你不难看出：

• 词汇表给出的都是业务术语，同时也给出了在特定业务场景下的含义
• 它也给出了相应的英文，省得你费劲心思去思考

遇到了一个词汇表中没有的术语，就找出这个术语相应的解释，然后补充到术语表。

用集体智慧，而非个体智慧。你一个人的英语可能没那么好，但一群人总会找出一个合适的说法。业务词汇表也是构建通用语言的一部分成果。

英语单词的拼写错误

我再给你看一段曾经让我迷惑不已的代码：

public class QuerySort {
    private final SortBy sortBy;
    private final SortFiled sortFiled;
    ...
}

初看这段代码时，我还想表扬代码的作者，他知道把查询的排序做一个封装，比起那些把字符串传来传去的做法要好很多。

但仔细看，sortFiled 是啥？排序文件吗？为啥用的还是过去式？归档？

找出这段代码的作者，向他求教，果然他把单词拼错了。

偶尔的拼写错误不可避免，国内的拼写错误比例是偏高的。

像 IntelliJ IDEA 这样的 IDE 甚至可以给你提示代码里有拼写错误（typo），只要稍微注意一下，就可以修正很多这样低级错误。

总结

两个典型的命名坏味道：

不精准的命名；

用技术术语命名。

命名是软件开发中两件难事之一（另一个难事是缓存失效），不好的命名本质上是增加我们的认知成本，同样也增加了后来人（包括我们自己）维护代码的成本。

• 好的命名要体现出这段代码在做的事情，而无需展开代码了解其中的细节
• 再进一步，好的命名要准确地体现意图，而不是实现细节
• 更高的要求是，用业务语言写代码

好的命名，是体现业务含义的命名。

几个英语使用不当造成的坏味道：

• 违反语法规则的命名
• 不准确的英语词汇
• 英语单词的拼写错误

还有一些常见的与语言相关的坏味道：

• 使用拼音进行命名
• 使用不恰当的单词简写（比如，多个单词的首字母，或者写单词其中的一部分）

如何从实践层面上更好地规避这些坏味道：

• 制定代码规范，比如，类名要用名词，函数名要用动词或动宾短语
• 要建立团队的词汇表
• 要经常进行CR

编写符合英语语法规则的代码。