别让变量名毁了可读性：JavaScript 命名的“潜规则”与实战心法

接手过旧项目的同事可能都懂那种痛：打开代码文件，满屏的 var list, const data, let temp。六个月后再看自己的代码，连自己都要重新猜这个变量到底装的是用户列表还是订单数据。糟糕的命名是维护成本的隐形杀手，它不仅拖慢开发速度，还容易埋下逻辑隐患。

好的命名习惯不是为了迎合文档标准，而是为了降低沟通成本。当你在团队中协作时，变量名就是你无声的注释。

语义化优先于简洁

很多人为了偷懒，喜欢用缩写或单字母代替含义。但在业务逻辑复杂的系统中，全称往往比缩写更友好。比如定义一个数组，用 users 远比 u 或 usrs 清晰；获取用户信息时，用 userInfo 而不是简单的 info。

不要过度追求字符短小。如果你的变量名需要你在心里翻译三秒才能理解，那就说明它不合格。哪怕多敲几个键，使用 fetchCurrentUserProfile 也比 getInfo 要精准得多。让变量名直接表达它的用途和返回的内容类型，这是消除歧义的第一步。

布尔值的“前缀法则”

处理状态值时，Boolean 类型的命名最容易被忽略。如果你定义了表示状态的变量，请务必加上明确的前缀。使用 isLoading, hasPermission, canSubmit 这样的命名方式，能瞬间提升代码的可读性。

想象一下，如果代码里出现了一个孤零零的 valid 或 status，其他开发者很难第一时间判断这是真值还是状态码。而 isValid 或 isDisabled 则一眼就能明白它代表一种条件判断。遵循 is, has, can, should 等前缀规范，能让逻辑分支的意图变得一目了然，减少误判风险。

常量与大写的边界

很多新手会把所有常量的首字母变大写，甚至全部大写。实际上，全大写字母通常仅用于真正不可变的配置项或环境变量，例如 MAX_RETRY_COUNT 或 API_BASE_URL。对于普通的函数内部常量，或者虽然当前没变但未来可能调整的逻辑值，保持驼峰命名（camelCase）更为合适。

此外，关于下划线的使用也要谨慎。虽然 _privateVar 在视觉上暗示私有属性，但在 JavaScript 中这只是一种约定而非强制限制。除非你有特殊的框架约束或团队协作规范，否则尽量避免滥用下划线作为变量名的开头，以免混淆内置方法或特殊对象。

复数形式与动作动词

当变量是一个集合时，务必使用复数形式。item 指向单个对象，而 items 明确表示这是一个数组。这不仅符合英语语法直觉，也避免了在处理循环逻辑时的思维卡顿。同样，涉及异步操作或函数返回值时，动词的选择也很关键。获取数据用 fetch，解析结果用 parse，清理缓存用 clear。动词与名词的搭配应当符合自然语言的表达习惯。

总结

代码是写给机器执行的，更是写给人阅读的。一套良好的命名规范，本质上是建立一种团队间的信任契约。不需要死记硬背枯燥的规则，只需在每次提交代码前自问一遍：“如果我是接手这个项目的新人，看到这个名字能立刻明白它在做什么吗？”

从拒绝 tmp 开始，把变量名当作技术资产来打磨。你会发现，当命名清晰了，调试的时间变少了，代码重构的难度也低了。这不仅是规范的胜利，更是专业度的体现。