不管是日本人设计的 Ruby还是巴西人设计的 Lua,各种语法采用的全都是英语。所以,想要成为一个优秀的程序员,会用英语写代码是必要的。
但不是要求研发人员都得专业英语八级,但至少确保代码用英语表达你的意图。
CR一段代码:
乍看写得还不错,将一些章节信息标记为翻译完成。似乎方法名也能表达这意思,但经不起推敲。 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),只要稍微注意一下,就可以修正很多这样低级错误。
今天我们讲了几个英语使用不当造成的坏味道:
还有一些常见的与语言相关的坏味道:
如何从实践层面上更好地规避这些坏味道:
编写符合英语语法规则的代码。