怎样的变量命名，才显得有文化？

程序笔记 2024年11月28日23:31

相信不少程序员都为变量命名这个问题伤透了脑筋。变量名太短了别人看不懂，太长了又显得啰嗦，不长不短又考验词汇量，一不留神就跟已有变量名重复。取得一手好名字确实是一个挑战，也是一门艺术。今天我们就来聊聊，到底要怎样命名，才能显示出水平？

不同的编程语言有不同的具体命名规范，通常包含在语言的风格指南里。本文不打算讨论各种语言的代码风格问题，只讨论跟具体语言无关的命名准则。

为什么需要命名规范

从本质上来说，变量名只是个标识符，用于表示内存中的一个地址或者数据。按理说只要符合编程语言的语法规则，无论怎么命名都不会影响代码的执行结果。那为什么我们还要强调命名规范呢？记得有人说过，代码首先是给人看的，其次才是计算机。代码在执行前，通常要经过作者深思熟虑的编写，甚至同行评审（code review）过后，确保没有明显的问题才会交给计算机执行。计算机只负责编译执行，才不管你的代码写得好不好看，有没有逻辑问题，扩展性如何等等。从这个角度说，良好的命名规范可以提高代码质量，减少软件缺陷。

良好的命名具有自文档的作用，看变量名就知道代表什么含义。无论对于团队成员协作还是自己维护代码，都很有意义。否则就会出现下面这种尴尬的局面：

什么是好的命名

在生活中，漂亮的人名让人赏心悦目，还有着丰富的含义，让人印象深刻。虽然说给变量命名不需要这么高的文学水准，但是也要具备一些基本的要素。个人认为，好的变量名通常具备以下几个特点。

符合代码风格
比如大小写要求，使用特定的字符表示特殊的含义，等等。这些按照特定语言的规范和团队规范来就行了。
长短适中
变量名不宜过短，也不宜过长。早些年编辑器不够发达，为了少打几个字母，能省则省，变量名往往很简短，喜欢用各种缩写。要是使用约定俗成的缩写还好，最怕那些用拼音首字母缩写的，看代码就像猜谜语。现在 IDE 如此强大，自动补全功能已经很完善了，完全没必要为了省那几个字母让其他人看得一头雾水。当然，也不是说越长越好，比如

function iCanNotReadTheNumberSoIWriteThisFunctionToTransformStringsToNumber() {}

这有点夸张了。记住一个原则：在足够表达含义的前提下尽量简短。

有意义的单词
变量名最好是一个有意义的单词，用来表示特定的含义，比如动作、属性、数据等。当然，这也不是绝对的。比如在for循环里用的i变量，已经约定俗成了，属于作用域范围很小的局部变量，用完即丢。这种情况可以使用简洁的命名。
有具体的含义
除了要有意义，还需要含义尽量具体。比如data，item，list等，虽然也能用，但是含义太泛了，不够具体。更好的名字是userProfile，orderItem，bookList等，一眼就能看出所代表的业务模型。
词性准确
属性、方法、类等命名所采用的词性也有讲究。方法（函数）通常代表了一个动作或者状态判断，所以应该用动词、系表结构、介词短语或者动宾结构。比如render，isPrototypeOf，toString，getOrders等。说到这里可能有人觉得有点装X了，是不是要把英语老师请过来？其实也不必过分解读，只要记住一个原则就行了，那就是方法代表了一个操作。这样你就不会用一个名词当做方法名。属性名通常使用名词，形容词，动词过去式等。类名基本用名词，代表了一种业务模型。
纯英文
这点没办法，谁让发明编程的人是说英语的呢。虽然从编程语法上来说，有时候也能用非英文做标识符，但是最好尽量避免这种不伦不类的做法。比如有人喜欢用拼音，甚至拼音和英语混着用。个别情况下可以用拼音，那是实在找不到对应的英文单词了。大部分情况下，用纯英文单词显得比较专业，以及，比较有文化（逼格）。还有就是，不要用中式英语！我见过太多的isModify，isDelete这种表达方式了，看得我尴尬癌都犯了。这种写法，内部几个人的项目也就罢了，如果是开源项目，拿出去都丢人啊！

以我多年的搬砖经验，见过一些在命名方面比较讲究的框架和库，比如微软的 .Net Framework，C# 的命名，用词准确、精炼，看起来就很舒服。还有就是 Vue.js，API 命名也相当优雅。那几个钩子函数，created，mounted，destroyed，activated，errorCaptured等等，简洁而不失准确，词义相当到位。而相比之下，React 就稍差了。什么componentDidMount，componentWillMount，shouldComponentUpdate……这一看就没什么文化嘛，表义有余而精炼不足。