Java命名规范被违反会降低可读性、掩盖逻辑、增加维护成本并引发隐患；类/接口须PascalCase（如UserInfoService、XmlParser）；变量/方法须camelCase（如userName、loadDataFromDb）；常量须全大写下划线（如MAX_RETRY_COUNT）；泛型用单字母（T、E），局部变量名需语义明确，测试方法名应表达场景与预期。
Java 命名规范被违反时，代码审查中常会直接标出问题，不是因为“看起来不美”，而是它会干扰可读性、掩盖逻辑意图、增加维护成本，甚至引发编译或运行时隐患。
类名和接口名未用 PascalCase
常见错误：用小写下划线（user_info_service）、全小写（databaseutil）或混合大小写（XMLParser但未统一首字母大写）。Java 要求类名和接口名必须是 PascalCase（首字母大写，无下划线），如 UserInfoService、XmlParser。IDE（如 IntelliJ）通常会标黄警告，CR 中也常被要求修改。特别注意缩略词——XML 在类名中应写作 Xml（即 XmlParser），而非 XMLParser 或 XmLParser。
变量/方法名使用下划线或驼峰不一致
典型问题包括：user_name（下划线分隔）、getUserName_2（数字后缀+下划线）、loadDataFromDB（DB 应为 Db）。正确写法是纯 camelCase，单词间首字母大写，缩略词视为一个单词且首字母大写（db→Db，id→Id）。例如：userName、loadDataFromDb、userId。方法名还应以动词开头（calculateTotal()），避免 totalCalculate() 这类倒置表达。
常量未全大写 + 下划线分隔
违反情形：用 maxRetryCount、DEFAULT_TIMEOUT_MS（大小写混用）、API_URL（全大写但用了下划线外的空格或连字符）。public static final 字段必须全大写，单词间用单个下划线连接，如 MAX_RETRY_COUNT、DEFAULT_TIMEOUT_MS、API_BASE_URL。注意：仅限编译期常量（字面量或 final static primitive / String）；若值来自配置或运行时计算，即使修饰为 final，也不应视作常量命名，而应按普通变量处理（如 apiBaseUrl）。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
泛型参数、局部变量或测试方法命名含糊或带冗余前缀
泛型类型参数应简短、大写字母为主（T、E、K、V），避免 ElementType 或 MyType；局部变量忌用 i、tmp、obj 等无意义名称，也不推荐加前缀如 strName、intCount（类型应由声明体现，非靠名字暗示）；JUnit 测试方法名应清晰表达场景和预期，如 shouldReturnEmptyListWhenInputIsNull()，而非 test1() 或 checkNull()。
命名不是风格偏好，是契约——它让其他开发者无需点进方法体就能理解作用域、生命周期和语义角色。一次不规范，可能节省 5 秒输入，却让团队每人多花 30 秒解读。审查时盯住这些点，其实是在守住协作的基本信号。
