Java命名规范强调可读性优先，缩写需首字母大写（如XmlParser）、禁用全大写（如XMLParser），单词按语义单元拆分（如parseHtmlString），常量全大写（MAX_RETRY_COUNT），包名全小写不缩写。
Java 命名规范对缩写和单词拆分有明确但易被忽视的约定，核心原则是：**保持可读性优先，兼顾一致性，避免歧义**。不是所有缩写都可大写，也不是所有复合词都按字面拆分。
缩写词在标识符中的大小写处理
Java 不鼓励全大写缩写（如 XMLParser），但允许常见、公认的首字母大写缩写（如 XmlParser、HttpServer、UrlEncoder）。关键看该缩写是否已在开发者社区中形成稳定读法。
- 公认缩写（建议首字母大写）：Xml、Http、Url、Html、Json、Csv、Io、Db、Sql、Uuid、Id
- 不推荐全大写：避免 XMLParser、HTTPServer（除非是常量全大写场景）
- 生僻或自定义缩写应避免：如把 “BusinessLogic” 缩成 BlProcessor 会降低可读性，应写为 BusinessLogicProcessor
- 两个及以上连续缩写需谨慎：如 HttpsUrlConnection 是可接受的（Https + Url + Connection），但 HTTPURLConn 就违反可读性原则
单词拆分以语义完整性为前提
拆分不是机械按空格或连字符切分，而是依据英语语义单元。比如 “isActivated” 不拆成 “isActi vated”，因为 “activated” 是完整过去分词；“computeUtf8Hash” 中 “Utf8” 是固定术语，不能拆成 “Utf 8”。
- 动词+名词组合：用驼峰自然衔接，如 loadConfiguration、validateEmailFormat
- 带连字符的英文词：按习惯读法转驼峰，如 “e-mail” → email，“co-worker” → coworker 或更推荐 collaborator（语义优于字面）
- 数字参与命名时：数字视为独立单元，不与字母粘连，如 version2Parser、bufferSize1024（但更推荐 bufferSize1k 或常量 BUFFER_SIZE_1024）
- 避免歧义拆分：如 parseHtmlString 清晰表达“解析 HTML 字符串”，而 parseHtmlstring（小写 s）易被误读为 “htmlstring” 这个生造词
常量、类名、方法名的差异化处理
同一缩写在不同上下文中大小写规则不同，需结合命名用途判断：
立即学习“Java免费学习笔记（深入）”；
- 类名/接口名：使用 PascalCase，缩写首字母大写，如 JsonConverter、UuidGenerator
- 方法名/参数名：使用 camelCase，缩写仍首字母大写，如 toJsonString()、findUserById()
- 常量（public static final）：全部大写+下划线，缩写也全大写，如 MAX_RETRY_COUNT、DEFAULT_HTTP_TIMEOUT_MS
- 包名：全小写，不使用缩写，如 com.example.usermanagement（不用 com.example.usrmgmt）
工具与团队协同建议
IDE（如 IntelliJ）默认遵循 Oracle 命名指南，但需手动开启检查；团队应统一缩写词表并写入代码规范文档。
- 启用 IDE 的 “Naming Convention” 检查，标记如 XMLParser 这类非常规写法
- 维护一份内部《常用缩写对照表》，例如：”cfg → configuration“、”svc → service“、”dto → data transfer object“，并注明是否允许缩写
- Code Review 时重点检查新出现的缩写：它是否在表中？是否被多人理解？是否比全称更清晰？
- 遇到模糊情况（如 “apiKey” 还是 “apiToken”），优先选更准确表达意图的词，而非更短的缩写
