变量命名用小驼峰，代码更整洁

变量命名绝非微不足道的格式细节，而是决定代码可读性、协作效率与长期可维护性的核心实践：遵循小驼峰规范、使用完整语义化词汇（如httpStatusCode而非httpCode）、布尔变量强制添加is/has/can前缀（如isActive而非active）、仅采纳行业公认缩写并严格保持大小写规则（如userId而非usrName）、确保同一上下文中命名模式高度一致（如统一用xxxTimeoutMs），更重要的是——命名决策必须在编码第一秒就明确，而非事后补救；一个精准的变量名，能让他人秒懂意图，省下数分钟理解成本，而一个模糊的名字，却会埋下持续猜疑与高危重构的隐患。

变量名写得对，代码读起来就顺；写错了，光看名字就得猜半天。小驼峰不是格式装饰，而是让变量自己“说话”的基本功。

变量名必须一眼看出它存什么

命名不是拼单词，是表达意图。比如 userLoginCount 比 ulc 或 tmp 多花不到 0.5 秒输入，但能省下同事 3 分钟理解时间。

• 用完整词组合：✅ httpStatusCode，❌ httpCode（HTTP 是标准缩写，保留全大写；status 不可省）
• 避免模糊泛称：✅ pendingOrderList，❌ list、data、info
• 数字结尾要带语义：✅ initialRetryDelayMs，❌ delay1、delay2

布尔变量必须带 is/has/can 前缀

不加前缀的布尔变量极易引发误读。比如 active 可能被当成普通状态字段，而 isActive 明确表示“是否处于激活态”，也天然兼容 JavaBean 的 getIsActive() 调用。

• ✅ isEmailVerified、hasPermission、canEdit
• ❌ active（语义模糊）、flag（完全无意义）、enabled（不如 isEnabled 直观）
• 注意：前缀后接形容词或过去分词，不是名词，如 ❌ isUser（类型判断，不该由变量承担）

缩写只在公认场景下使用，且大小写要守规矩

XML、HTTP、ID、URL 这类缩写是行业共识，可以全大写作为单词一部分；但自造缩写（如 usr、svc、cfg）一律禁止——除非整个项目统一定义了缩写表，且所有成员都熟记。

• ✅ xmlParser、httpClient、userId、urlBuilder
• ❌ xmlparser（首字母没大写）、XMLParser（首字母大写 → 大驼峰，该用于类名）、usrName（非标缩写）
• 特别注意：ID 是缩写，不是单词，所以是 userId，不是 userNameId 或 userid

别让上下文破坏一致性

同一个作用域里相似含义的变量，命名模式必须一致。否则一个叫 timeoutMs，另一个叫 retryDelay，第三个又叫 maxWaitTimeInMs，等于主动放弃可维护性。

• 配置项统一后缀：✅ connectTimeoutMs、readTimeoutMs、writeTimeoutMs
• 循环变量适度简化：✅ for (OrderItem item : orderItems)，❌ for (OrderItem o : list)（o 没上下文支撑）
• 私有字段不加下划线：✅ private String firstName;，❌ private String _firstName;（Java 中这不是规范，是干扰）

最常被忽略的一点：命名规范不是写完代码再检查的“附加项”，而是在敲下第一个字母时就要决定的事。一旦接受 tmp 或 data 这类变量名，后续逻辑越深，重构成本越高——因为名字已经和几十处逻辑耦合了。

终于介绍完啦！小伙伴们，这篇关于《变量命名用小驼峰，代码更整洁》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！