Java变量命名和作用域需协同设计：命名须见名知意（小驼峰、布尔加前缀、常量全大写下划线、禁模糊缩写），作用域应最小化（优先局部、慎用静态、块级更精准），二者共同保障代码清晰、安全与可维护。
Java变量命名和作用域不是两个孤立概念，而是紧密配合的代码基础。命名决定别人能否一眼看懂变量用途，作用域决定变量在哪儿能用、何时失效——两者共同影响代码的清晰度、安全性和可维护性。
变量命名：见名知意是底线
命名不是“能跑就行”，而是让后续阅读者（包括三个月后的你自己）不查上下文就能理解变量意图。
- 一律用小驼峰（lowerCamelCase）：如userEmail、isExpired、maxRetryCount；避免user_email或UserEmail
- 布尔变量加is、has、can等前缀：如isActive比status明确，hasPermission比flag可靠
- 常量全大写+下划线：如DEFAULT_TIMEOUT_MS、MAX_LOGIN_ATTEMPTS；必须用final static修饰
- 禁用模糊缩写：用numberOfOrders而非numOrd，用customerAddress而非custAddr（除非团队统一约定且广泛认知，如http、id、url）
- 避开关键字和类名：不能叫class、string、list，哪怕大小写不同（String是类，string仍易混淆）
作用域：按需最小化，拒绝“全局感”
变量越早声明、越晚离开作用域，就越不容易被误用或污染。不要因为“方便”就把变量提成成员变量。
- 优先用局部变量：在方法内部声明，用完即弃。例如循环计数器i、临时计算结果totalAmount都应限于方法内
- 实例变量只存对象状态：如private String name、private int age；避免把临时逻辑变量（如tempResult）塞进类里
- 静态变量慎用：仅用于真正跨实例共享的配置或工具状态，如public static final Logger LOGGER；禁止用static int counter做非线程安全计数
- 块级变量更精准：if/for内部声明的变量，生命周期严格限定在该块，比如String formattedDate = sdf.format(now)只在日志打印块里存在
命名 + 作用域组合实战建议
好的实践往往体现在命名与作用域的协同上：
立即学习“Java免费学习笔记（深入）”；
- 方法参数名体现用途：void processOrder(Order order, BigDecimal discountRate)比void processOrder(Order o, BigDecimal d)直观得多
- 同名但不同作用域要谨慎：避免方法参数userId和成员变量userId同名引发遮蔽（shadowing），可用this.userId = userId明确区分，或改参数名为inputUserId
- 布尔变量作用域越小越安全：比如boolean shouldRetry = response.isServerError()只在重试逻辑块内，不提升为字段，避免状态残留
- 常量命名+作用域匹配：接口中定义的配置常量用public static final，类内私有工具常量用private static final，既清晰又封装
容易忽略但关键的细节
这些点不难，但常因“差不多就行”被跳过，却直接影响长期可维护性：
- 所有变量必须显式初始化再使用：局部变量编译器强制要求，但别依赖默认值（如int count;未赋值就参与运算）
- 避免数字开头或纯数字命名：3rdPartyApi非法，100msTimeout也不推荐；改用thirdPartyApi、timeout100Ms
- 包名全小写、无下划线：com.example.auth ✔，com.example.AuthService ✘（类名才大驼峰）
- IDE能帮你检查：启用编译器警告（如“unused variable”）、开启Checkstyle或SonarQube规则，自动拦截a、tmp、data这类弱命名
