变量声明与命名规范是代码评审的关键防线，直接影响问题定位效率、可维护性及领域建模质量。需确保类型安全、见名知意、作用域合理、业务语义对齐。

变量声明与命名规范在代码评审中不是形式主义，而是快速定位问题、保障可维护性的第一道防线。评审时看到一个变量名，就能判断它是否被合理使用、生命周期是否清晰、意图是否明确——这比逐行读逻辑高效得多。

变量声明是否合规，直接暴露基础风险

声明不规范往往意味着开发者对Java类型系统理解不足，容易引发隐式bug。

• 基本类型未初始化就使用（如局部变量int count未赋值）会编译报错，但评审时仍需确认所有分支都覆盖赋值逻辑
• 引用类型声明后未判空就调用方法（如String name; name.length()）属于典型NPE隐患，评审要重点检查是否做了null guard
• 同类型多变量混用（如int a=1, b=2, c=0;）虽语法合法，但c的初始值易被忽略，建议拆成独立声明提升可读性
• 避免用$符号或数字开头（如$cache、1stValue），这类名字可能干扰IDE解析或与字节码生成器冲突

命名是否“见名知意”，决定评审效率高低

名字是代码的说明书。评审者不需要点进方法体，仅凭变量名就能推测用途、范围和约束。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 成员变量用小驼峰（userName、totalCount），静态常量全大写下划线（DEFAULT_TIMEOUT、MAX_RETRY）——不一致就说明上下文混乱
• 避免模糊缩写（如tmp、data、obj），换成具体语义名（userInputJson、retryDelayMs）更利于快速理解
• 布尔变量必须用is/has/can开头（isActive、hasPermission、canEdit），否则if (delete)这种表达极易引起歧义
• 循环变量别用i/j/k，除非是纯数学索引；业务场景下优先用userIndex、orderPos等带上下文的名称

作用域与生命周期是否匹配，反映设计意识

变量声明位置泄露了开发者的抽象能力。评审时顺手扫一眼作用域，就能发现潜在的设计缺陷。

• 方法内本该用局部变量的地方却用了类成员变量（如把count声明为private int count;却只在单个方法里累加），说明状态管理冗余
• static变量用于存储非全局状态（如static List tempResults;），会导致并发问题或内存泄漏，应改为方法内局部变量
• for循环外声明循环变量（如int i = 0; for (i = 0; i
• 参数未声明final（如void process(User user)），后续修改可能意外改变入参，影响方法幂等性和可测试性

命名与业务语义是否对齐，体现领域建模质量

好的变量名不是技术术语堆砌，而是业务语言的自然映射。评审时可对照需求文档验证一致性。

• 订单系统中出现orderNo、orderId、orderCode混用，需统一为orderId（若ID是主键）或orderNumber（若为业务编码）
• 金额字段必须明确单位和精度，如totalAmountCents（整型分）、unitPriceYuan（双精度元），避免total、price等模糊表述
• 时间字段注明时区或语义，如createdAtUtc、expiryDateLocal、lastLoginTimeMs，防止时序逻辑出错
• 枚举或常量类中的字段名应与业务术语一致（如PaymentStatus.PAID而非PaymentStatus.SUCCESS）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南