通常，变量(广泛地包含函数名)命名的长度似乎显而易见是不会存在什么标准参考值的。我也不假思索地接受这个说法。但在实际操作中，我又隐约感觉到应该是需要有个标准的，不然风格就容易乱了。这绝对不仅仅是出于美学观点的考虑。
有些老编译器，对变量名的长度是有限制的，比如有严格的 8位，当变量名超过 8位 时编译器会进行截取而不是报错，于是 student_name == student_number，程序运行结果错得离谱。当然现在用上这种很上年纪的编译器的几率微乎其微，但是就可以乱来了吗？
虽然长度不限，但编程教程上会有这种指示：变量名不应太长。而我觉得这几乎是跟没说一样。
多长才算太长呢？我就发现有些人喜欢用很长的名字，比如 lengthOfPrerogativeName ，如果只是像 lengthOfPrerogativeName++ 这样用用还好，但如果是
lengthOfPrerogativeName = lengthOfPrerogativeName +
(lengthOfPrerogativeName > 0 ? "." + lengthOfSubPrerogativeName);
我反正是看着就头晕。而且这还不是极端情况，当整个代码都充斥这些 long long things 之后，很多行就会因为超过 80 个字符而需要换行，整体看起来是美观了，但是每行代码所能表达的意思就少了，不够完整了，比如上面那个简单的拼接操作竟然也需要两行。
不过似乎有人更加担心，如果名字太短就看不出来这个变量是干什么用的。但我更加担心长久面对这种代码，在搞清楚代码在表述什么功能之前，首先要花费不少时间去“阅读”变量名，而且稍有不慎，错误一触即发。
变量名短些，代码看起来会比较清晰。这实际上是利用了人脑的临时记忆功能，但如果所有名字都短，有更多含义隐藏在字下面，就变相要求代码阅读者去记忆那些变量的含义，这也会让我头晕的。比如：
int a, b, c, d, e, f; a = name.length; b = subName.length; c = a > 0 ? 1 : 0; c = a + c + b; d = 2 * a + c e = d + b; f = e - c;
虽然这代码没什么实际意义，但是也要花点时间瞄清楚了才会发现，是不是很上当的感觉，特别是在找 bug 的时候，可想而知有多痛苦。
代码过程中免不了重构。如果一个短名，如“i”，到处使用，而又需要改下名字的时候，如果粗略地全替换是保证出错的。如果编辑器缺乏对重构的一些有利帮助，那就注定了是一场费力而且容易出错的风险作业。
正如这篇讨论所总结的，“our conventions for naming things should take into consideration the limitations of the human brain”。如果是作为全局变量，长度约为 10-20 比较合适，全部大写会更醒目；只在一个循环里面用到的，”i” 就足够了。
通常代码里都不止这两种情况，不过可以按照同样的思路在推断，到底多长比较合适。不同的作用域从小到大，其合适长度在增大。长度大，不容易重复，而且有利于分辨，比如全局变量。类一级的，单词或词组，关键是要清晰表达变量所指。方法里面，单词或者缩写，代码块内，简写甚至单个字母，要考虑更简洁清晰地表达流程和功能。
单就长度而论，规则可以是相当清晰明确的。最终都是为了让代码有更好的表现力，阅读起来更加流畅，除了在长度上使用一致的规范，在数量上，功能分布上都应该有所设计。
代码是给人看的，是人与机器之间交流用的，也是人和人之间交流用的，它也有变美丽的要求。