变量声明与命名规范是代码评审的关键防线，直接影响问题定位效率、可维护性及领域建模质量。需确保类型安全、见名知意、作用域合理、业务语义对齐。
变量声明与命名规范在代码评审中不是形式主义，而是快速定位问题、保障可维护性的第一道防线。评审时看到一个变量名，就能判断它是否被合理使用、生命周期是否清晰、意图是否明确——这比逐行读逻辑高效得多。
变量声明是否合规，直接暴露基础风险
声明不规范往往意味着开发者对Java类型系统理解不足，容易引发隐式bug。
- 基本类型未初始化就使用（如局部变量int count未赋值）会编译报错，但评审时仍需确认所有分支都覆盖赋值逻辑
- 引用类型声明后未判空就调用方法（如String name; name.length()）属于典型NPE隐患，评审要重点检查是否做了null guard
- 同类型多变量混用（如int a=1, b=2, c=0;）虽语法合法，但c的初始值易被忽略，建议拆成独立声明提升可读性
- 避免用$符号或数字开头（如$cache、1stValue），这类名字可能干扰IDE解析或与字节码生成器冲突
命名是否“见名知意”，决定评审效率高低
名字是代码的说明书。评审者不需要点进方法体，仅凭变量名就能推测用途、范围和约束。
- 成员变量用小驼峰（userName、totalCount），静态常量全大写下划线（DEFAULT_TIMEOUT、MAX_RETRY）——不一致就说明上下文混乱
- 避免模糊缩写（如tmp、data、obj），换成具体语义名（userInputJson、retryDelayMs）更利于快速理解
- 布尔变量必须用is/has/can开头（isActive、hasPermission、canEdit），否则if (delete)这种表达极易引起歧义
- 循环变量别用i/j/k，除非是纯数学索引；业务场景下优先用userIndex、orderPos等带上下文的名称
作用域与生命周期是否匹配，反映设计意识
变量声明位置泄露了开发者的抽象能力。评审时顺手扫一眼作用域，就能发现潜在的设计缺陷。
立即学习“Java免费学习笔记（深入）”；
- 方法内本该用局部变量的地方却用了类成员变量（如把count声明为private int count;却只在单个方法里累加），说明状态管理冗余
- static变量用于存储非全局状态（如static List<String> tempResults;），会导致并发问题或内存泄漏，应改为方法内局部变量
- for循环外声明循环变量（如int i = 0; for (i = 0; i < list.size(); i++)）破坏了作用域最小化原则，增加误用风险
- 参数未声明final（如void process(User user)），后续修改可能意外改变入参，影响方法幂等性和可测试性
命名与业务语义是否对齐，体现领域建模质量
好的变量名不是技术术语堆砌，而是业务语言的自然映射。评审时可对照需求文档验证一致性。
- 订单系统中出现orderNo、orderId、orderCode混用，需统一为orderId（若ID是主键）或orderNumber（若为业务编码）
- 金额字段必须明确单位和精度，如totalAmountCents（整型分）、unitPriceYuan（双精度元），避免total、price等模糊表述
- 时间字段注明时区或语义，如createdAtUtc、expiryDateLocal、lastLoginTimeMs，防止时序逻辑出错
- 枚举或常量类中的字段名应与业务术语一致（如PaymentStatus.PAID而非PaymentStatus.SUCCESS）
