一、话题背景
在软件开发领域，代码的可读性是一个不容忽视的问题。一个常见的挑战是变量命名的规范性。不规范的定义和随意的命名习惯常常使得研发人员难以理解变量的具体含义及其用途。
那当研发人员没有写注释时，这就要求在写变量名称的时候，需要让其他研发同学看得懂这是什么意思，它的用途是什么。如果看不懂的情况下，乱猜的场景下，就可能导致传错参数，出现bug。
那么就有同事提出了这几种变量命名选项：
- 方式一：英文直译，直观，但是一旦遇到复杂的定义时，命名的名称就可能很长了。
- 方式二：一定程度的缩写，大概率能猜测出来，感觉不怎么好看。
- 方式三：完整缩写，如果不写注解，完全看不出意思；大部分代码都不写注解的。
所以面对这些命名选项，大家认为哪种方式更为合适，或者是否有其他更好的命名方式呢？
二、鹅厂工程师的看法
1.
miey-S1安全规划中心应用研究员
骆驼命名法挺好使的，混合使用 拼音/英文单词/单词缩写 构成变量和函数的名字。StudentNum、student_num，如果不是 num、cnt、idx、len、avg、obj、pkg、func、info 等等耳闻能详的缩写，就没必要强行缩写了
另外，这个方式三....真的有被笑到
2.
lakhdar-TEG应用开发工程师
studentNum，太长的话用缩写+注释。
3.
chuan-CDG应用开发工程师
num 和 number 是一个有二义性的词汇，不要使用。 它既可以表示总数，也可以表示序号。
有人会认为 studentNumber 天然是学生数量的意思，但是通常 idNumber 就不是id数量的意思，而是身份证号。
那么 carNumber是汽车数量的意思，还是汽车号码的意思呢？这就让代码复杂化了。
studentCount 是一个一般好的名字，studentCnt是一个更好的名字。
All you need is Code Complete（《代码大全》）
4.
krisjc-TEG运营开发工程师
studentCount。
我个人觉得变量名不怕你起得长，就怕你起得短。不然后来人看你的代码一脸懵，可读性才是第一位的。
“我们要规避过于罕见或者根本不常用的单词，甚至是自己创造的词语，那更是禁忌，毕竟代码是给人读的，而不是什么过于抽象的艺术作品。”
5.
kernbin-WXG客户端开发工程师
视情况而定吧，如果上下文给足了信息，比如这是一个局部变量，在一个很短的名为 CountNumberOfStudent 的小函数里，那么我觉得可以短一些，二或者三都可以，因为信息足够了。
如果这是个全局变量（先不谈全局变量是否要加 g_ 之类的前缀）或者某个很复杂很大的函数里，那么我觉得名字应该足够长足够完整。因为在这个变量用到的上下文中信息不一定充足。
6.
n-TEG后台开发工程师
除非是业界习俗或公认，一个单词截一部分的应该排斥。
以下是几个坏例子：
- stNum
- stuNum
- studNum
- studeNum
- studenNum
7.
langdon-IEG运营开发工程师
变量名长度和作用域正相关。可以参考《代码整洁之道》clean code。
另外， IDE+AI时代，似乎没有必要用numStuds这种不节约几个字母，还容易造成歧义的缩写，除非stud的写法取得局部共识。
8.
kairee-IEG UI开发工程师
studentCount, studentNumber。
为什么要在意变量名称长？难道是用纸和笔写代码吗？
9.
kael-TEG运营开发工程师
变量取名实际上服务于代码阅读人。这个代码阅读人可以是你是你的团队，也可以是只有你自己。
通常来说，为了保障团队的阅读，应使用描述足够准确和无歧义的名字。
如果存在某段代码，后续永远不用修改和维护，或者只用运行一次，那么名称的长短就不那么重要了。例如临时编写的脚本，用完就删的那种。
还有一种极端的情形，在类似ACM的竞赛中，通常就会把名字取成和题目描述中一致，包括x,y,z,n,m,q,p这种。一方面是能够在争分夺秒的比赛中快速打码，另一方面是与原题中变量语义保持一致，减少反复读题的变量转换理解的开销，本身也可以增加阅读效率。
