简介这份华为内部Java编码规范PDF面向企业Java开发者、团队技术负责人及准备校招与认证考试的学习者用于解决团队代码风格不统一、可读性与可维护性差等实际问题也可作为代码评审与规范落地的对照依据。资源为单文件压缩包共1个pdf文档约90KB轻量易存便于随时代码查阅或打印成纸质规范手册。内容覆盖缩进与分界符、命名规则、代码组织与空行、注释规范、异常处理等模块如程序块统一4个空格缩进、大括号独占一行并左对齐、长表达式在低优先级操作符处折行、一行只写一条语句、对齐禁用TAB键以及类与接口、成员变量、公有和保护方法的注释模板非RuntimeException必须在方法注释中标明等要求并规定源程序有效注释量须在30%以上。目前已有982人学习浏览适合希望统一编码风格、提升代码质量与协作效率的开发者参考。1. 华为JAVA编码规范.pdf 到底在管什么代码评审里吵得最凶的往往不是算法对不对而是命名像不像人话、异常有没有被吞、日志级别用得对不对。华为JAVA编码规范.pdf 这类文档要解决的正是这批「人人都知道该做、但没人真的逐条盯」的问题。它把散落在团队口头约定里的规则固化成可检查、能在 IDE 里直接报错的条款覆盖命名、常量、包结构、异常、日志、并发与集合使用等高频区。适合谁写业务代码的后端、做平台工具链的人以及想把团队代码从「能跑就行」拉到统一水位的人。标题里的关键词是 JAVA 与编码规范重点不在语言本身而在如何把规范变成工具链里的硬门槛——让 java基础 阶段就该养成的习惯靠工程手段而不是靠自觉去兜底。2. 华为JAVA编码规范里的命名与结构硬约束规范文档里最容易被轻视、实际评审命中率却最高的部分是命名和结构。命名写错不会编译报错但会一路把可读性拖垮重构时也没人敢动。Java 是强类型加包管理的语言命名和包路径一旦混乱反射调用、依赖注入、序列化框架都会跟着出问题。所以这类规范通常把命名放在最前面并尽量用正则表达方便交给工具做校验。下面把常见条款拆成可直接对照的两张模板先说规则再说怎么被工具读进去。2.1 类名、方法名、常量名的命名规则怎么读规范里对命名对象是分类约束的每类对象对应一种形态越界就报错。很多 java面试八股文 里背过的「类名大驼峰、常量全大写」落到工程里其实就是几条正则。差别在于面试记住就行工程里必须写进检查配置否则换个人就写回原样。对象规则正例反例类 / 接口 / 枚举大驼峰 UpperCamelCaseOrderServiceorderService、order_service方法小驼峰、动词或动宾开头queryByIdQueryById、query_by_id常量static final全大写、下划线分隔MAX_RETRY_TIMESmaxRetryTimes成员变量 / 参数小驼峰userListuser_list、UserList包名全小写、点分com.example.ordercom.Example.Order布尔字段不用 is 前缀enabledisEnabled命名规则的实现方式通常在代码里长这样左边是违规写法右边是规范写法// 反例类名小写、常量驼峰、方法首字母大写 public class orderService { private static final int maxRetryTimes 3; public void QueryById(long Id) { /* ... */ } } // 正例 public class OrderService { private static final int MAX_RETRY_TIMES 3; public void queryById(long id) { /* ... */ } }逻辑说明类名走大驼峰是为了和变量名区分一眼能看出这是类型常量全大写加下划线是历史最久、工具支持最广的约定Checkstyle 的ConstantName默认规则就是这条。参数名id用小写单个词是为了避免和类型名冲突时产生视觉歧义。参数说明上MAX_RETRY_TIMES这种常量名一旦改了命名形态等于打破了全团队对「这是编译期常量」的默认认知所以这类规则值得进硬检查。2.2 包结构与分层约定的检查方式除了单个名字规范还会约束包的组织方式。常见做法是按分层切包controller、service、dao、domain、util各占一层包名一律小写不允许出现大写或下划线。原因很实际——包名大小写在不同操作系统上表现不一致本地能跑、放到构建机上就找不到类这类问题排查起来极其费时。检查包结构通常分两步一是包名格式交给 Checkstyle 的PackageName二是依赖方向比如controller能否直接依赖dao、工具类是否被业务层反向引用这类跨文件规则单文件检查器做不到需要用 PMD 或自定义依赖检查。分层本身不产生编译错误但它决定了后续能不能干净地替换实现、能不能做模块化拆分。一个典型的落地形式是在构建脚本里对包依赖做白名单。常见做法是允许controller → service → dao禁止反向和跨层直达命中违规直接失败。工具层面这属于架构约束命令行的静态检查器覆盖有限更多团队会借助 ArchUnit 这类测试来断言包依赖。命名和结构两条线合起来才构成编码规范里真正能被自动验证的那一半。3. 把规范落到工具链Checkstyle 与 IDEA 的具体配置命名和结构规则如果没有工具兜底就只能靠评审口头提醒效率低还容易得罪人。真正让规范落地的做法是把它翻译成一份 Checkstyle 配置再挂到 IDE 和构建两端。IDE 端负责在写的时候就把违规点亮构建端负责在提交时把违规拦下。两端用同一份配置文件才不会出现「本地不报、CI 报错」的割裂。下面给一份最小可用配置覆盖前面讲的命名和结构条款。3.1 用 Checkstyle 把命名和结构规则写成可执行检查配置文件本质是一个模块树Checker是根文件级规则直接挂在根下需要解析到语法节点的规则挂在TreeWalker下。命名规则都属于后者。?xml version1.0? !DOCTYPE module PUBLIC -//Checkstyle//DTD Checkstyle Configuration 1.3//EN https://checkstyle.org/dtds/configuration_1_3.dtd module nameChecker !-- 文件级文件末尾必须有换行、禁止 Tab 缩进 -- module nameNewlineAtEndOfFile/ module nameFileTabCharacter/ module nameTreeWalker !-- 类型名大驼峰 -- module nameTypeName/ !-- 方法名小驼峰默认正则即 ^[a-z][a-zA-Z0-9]*$ -- module nameMethodName/ !-- 常量名覆盖默认强制全大写下划线 -- module nameConstantName property nameformat value^[A-Z][A-Z0-9_]*$/ /module !-- 成员变量小驼峰 -- module nameMemberName/ !-- 包名全小写、点分不含大写和下划线 -- module namePackageName property nameformat value^[a-z](\.[a-z][a-z0-9]*)*$/ /module /module /module逻辑说明TreeWalker下每个module是一类检查name对应内置检查器property用来覆盖默认参数。ConstantName的关键在于默认格式只禁小写开头不加约束的话驼峰常量照样能过所以必须显式改成^[A-Z][A-Z0-9_]*$。FileTabCharacter这类看似无关的规则实际是为了统一缩进避免 git diff 因 Tab 和空格反复打架。参数说明format是正则命中才算合规severity可在模块或全局设置取值error、warning、info决定违规的严重级别也决定构建时是否直接失败。下表把常用检查器和它对应的违规面列清Checkstyle 模块检查内容典型违规TypeName类 / 接口 / 枚举名orderServiceMethodName方法名QueryByIdConstantNamestatic final 常量名maxRetryTimesMemberName成员变量名user_listPackageName包名com.Example.orderFileTabCharacter缩进字符使用 TabNewlineAtEndOfFile文件结尾缺少换行符3.2 IDEA 里实时校验与保存自动修正配置写完只放在仓库里没用得让它在编辑器里跑起来。装 Checkstyle-IDEA 插件后把上面那份 xml 加进插件的配置文件列表指定版本和扫描范围编辑器就会在违规处画波浪线。这一步的价值是把反馈从「提交后 CI 报错」提前到「打字时就亮红」改起来几乎零成本。插件里我一般会做三件事把配置文件设为项目级、开启实时扫描、把严重度映射到编辑器告警级别。这样团队成员拉下项目就自带同一套规则不用各自配。自动修正只对能安全改的规则开启比如文件末尾换行、多余空格命名类规则不轻易让工具自动改因为改名可能动到调用方属于重构范畴交给人工或专门的 IDE 重构功能更稳。这里有个常见误区把error级别一口气全开结果团队第一天就被上千条历史违规淹没直接放弃。更可行的顺序是先全设warning跑一段时间把新增代码清零再针对核心命名规则单独提级逐步收紧。4. 在 Maven 与 CI 流水线里卡住违规提交IDE 靠自觉构建机靠强制两者缺一不可。把 Checkstyle 挂到 Maven 生命周期上就能在mvn verify阶段直接失败让不符合规范的代码连合并都过不去。这一步是把编码规范从「文档」变成「门槛」的关键也是很多 java后端 团队真正开始收敛代码风格的分水岭。配置本身不复杂难在怎么梯度上线、怎么处理历史存量。4.1 Maven 集成 Checkstyle 与 PMD 的最小配置在pom.xml的build里挂插件指向仓库内那份 xml并绑定到校验阶段。版本号统一走属性管理避免散落在各处properties checkstyle.plugin.version!-- 与团队锁定版本一致 --/checkstyle.plugin.version /properties plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId version${checkstyle.plugin.version}/version configuration !-- 指向仓库内的规则文件保证本地和 CI 一致 -- configLocationconfig/checkstyle.xml/configLocation !-- 违规即失败 -- failsOnErrortrue/failsOnError consoleOutputtrue/consoleOutput /configuration executions execution idcheckstyle-verify/id phaseverify/phase goals goalcheck/goal /goals /execution /executions /plugin逻辑说明configLocation用相对路径指向仓库文件是为了让本地和 CI 读到同一份规则避免谁在本地改了规则却没提交。phase设为verify而不是更早的阶段是因为要等编译产物齐全后统一检查减少无谓的重复扫描。consoleOutput打开后违规会直接打进构建日志排查时不用再去翻报告文件。命令行验证时直接跑# 单独触发检查快速定位违规 mvn checkstyle:check # 走完整生命周期观察 verify 阶段是否拦截 mvn clean verify # 需要绕过时谨慎使用显式跳过 mvn verify -Dcheckstyle.skiptrue参数说明mvn checkstyle:check只跑检查不触发构建适合本地快速修-Dcheckstyle.skiptrue是逃生通道规范里通常要求只在紧急修复时用且事后必须补回。下表演示常见阶段和行为的关系阶段 / 命令动作违规时的行为IDE 实时扫描编辑时高亮波浪线提示不阻断mvn checkstyle:check手动触发控制台报违规列表mvn verify绑定阶段生命周期自动触发按failsOnError决定是否失败-Dcheckstyle.skiptrue显式跳过不检查直接通过4.2 渐进式阻断从警告到失败新规则直接开check会炸出一堆历史债务务实做法是分三步走。第一步只出报告把failsOnError设为false让违规先可见第二步统计违规数量、按模块分批清理重点先清命名和吞异常第三步存量清零后再把阈值收紧到失败。这套节奏能让规范在几周内平稳落地而不是在评审会上被动喊口号。还有一个细节值得注意把checkstyle.xml纳入版本控制后任何改动都要走评审否则有人随手加个suppress就把规则关了。规则文件本身也需要有人维护定期对照上游规范做增量。5. 异常、日志与并发约定的进阶校验命名这类规则工具直接支持异常和日志却更依赖语义单文件检查器只能覆盖一部分。最典型的是空catch吞异常Checkstyle 有EmptyCatchBlock模块能抓但「catch 之后只打日志不处理」这种半吞就得靠自定义规则或评审。常见做法是要求异常要么处理、要么往上抛且带上原始异常做 cause方便定位根因。// 反例吞异常线上出问题无从查起 try { loadConfig(path); } catch (Exception e) { } // 正例记录关键上下文保留原始异常链后向上抛 try { loadConfig(path); } catch (IOException e) { log.error(加载配置失败, path{}, path, e); throw new BizException(CONFIG_LOAD_FAIL, e); }日志部分的进阶口径是级别要与语义匹配调试信息用debug、正常业务流转用info、可恢复异常用warn、不可恢复用error禁止用System.out打日志。参数化占位符{}必须用字符串拼接在大循环里会白白产生大量临时对象。并发上规范通常要求线程池手动创建并给线程命名便于线上排查和监控约定项要求原因线程池创建手动ThreadPoolExecutor避免无界队列拖垮机器线程命名自定义ThreadFactory日志和堆栈里能认出业务集合选择并发场景用ConcurrentHashMap防并发读写数据错乱锁粒度缩小同步块范围减少争用、避免死锁验证方法上EmptyCatchBlock和IllegalCatch可以进 Checkstyle线程池命名和集合选择更适合用 ArchUnit 或代码评审把关。一个实用技巧是把error级别日志里是否带异常栈、是否带请求标识写成评审清单固定下来——工具抓不到的地方靠清单把口径钉住比反复口头强调可靠得多。本文还有配套的精品资源点击获取