小驼峰命名法是团队协作的接口契约而非拼写习惯，要求布尔变量以is/has/can开头、缩写可推导、长度服从语义完整性，并强制跨作用域一致性。
小驼峰命名法不是拼写习惯，而是接口契约
变量名在 Java 或 JavaScript 中不是仅供编译器识别的符号，它实质上是开发者之间最轻量、最高频的“接口文档”。userLoginCount 和 ulc 在语法上都合法，但前者让协作者无需跳转、无需猜测就能确认语义；后者则必然触发一次上下文回溯或口头确认——这就是协作成本的直接来源。
小驼峰（camelCase）之所以成为主流，并非因为“看起来顺眼”，而是它天然适配英语母语者的阅读节奏：单词边界靠大小写提示，而非下划线或空格干扰视觉流。团队一旦统一采用，相当于默认所有人共享同一套“词法解析器”。
布尔变量必须用 is/has/can 开头，否则破坏调用直觉
JavaBean 规范早已将 isXXX() 与布尔属性绑定，IDE 自动生成 getter、框架序列化、Mock 工具反射都依赖这个约定。如果定义 active 字段却不加前缀，调用方看到 user.getActive() 无法判断返回值类型；而 isActive 一目了然。
-
isEmailVerified✅ 调用时自然读作 “is email verified?” -
emailVerified❌ 读作 “email verified” 像个名词短语，语义断裂 -
canRetry✅ 表达能力，且与if (canRetry) { ... }逻辑一致 -
retryFlag❌flag是典型语义黑洞，完全丢失状态本意
缩写必须可推导，禁用“仅自己懂”的简写
缩写本身不违规，但前提是团队成员能在 1 秒内还原全称。像 xmlParser、httpStatusCode 中的 xml 和 http 是通用技术缩写，无需解释；而 ulc、svc、tmpData 则属于危险缩写——它们不携带上下文线索，也不符合任何行业惯例。
判断是否可用缩写，就看它能否通过“反向拼读测试”：userId → “user ID” ✔️，usrId → “usr ID”？✘（usr 不是标准缩写，且破坏小驼峰首字母小写原则）。
- 允许：
urlPath、jsonBody、maxRetryTimes - 禁止：
uId（应为userId）、req（应为request或httpRequest）、cfg（应为config）
命名长度要服从语义完整性，不是越短越好
很多人误以为小驼峰 = 简洁，于是把 orderItem 缩成 oi、customerAddress 缩成 custAddr。这类缩写在单行循环中或许可容忍，但一旦出现在方法参数、类字段或日志输出里，就会立刻放大理解负担。
真实协作场景中，变量名被阅读的次数远大于被书写的次数。多敲几个字母换来的清晰度，远高于节省几毫秒的输入时间。
- 循环内临时变量可适度简化：
for (OrderItem item : orderItems)✔️ - 业务字段必须完整表达：
shippingAddressLine1✔️，shipAddr1❌ - 配置项保持模式一致：
connectTimeoutMs、readTimeoutMs、writeTimeoutMs✔️
最容易被忽略的是跨作用域一致性——比如一个模块里同时出现 userName 和 user_name，哪怕只有一处，也会动摇整个命名体系的可信度。小驼峰不是风格选项，是团队代码的语法底层。
