合并请求（Merge Request）审查是否应包含代码风格检查？跨项目遇风格问题如何解决

多团队代码规范不统一问题的解决方案 #

• 优先落地全链路自动化校验工具，Java、Kotlin生态已有成熟的开箱即用方案：
  • Java生态可使用CheckStyle做代码风格校验、SpotBugs做静态代码检查
  • Kotlin生态可使用ktlint做风格校验、detekt做静态代码检查
  • 各项目将对应规则配置文件存放在项目根目录，IDEA等主流IDE可直接导入配置实现保存自动格式化，无需开发者手动记忆规则
  • 将风格校验步骤集成到CI流水线，MR提交时自动触发校验，不满足规则的直接阻断合入，无需评审人人工指出风格问题
• 拉通跨团队规则对齐，减少不必要的差异化要求
  • 公司层面组织各团队技术负责人对齐Java、Kotlin通用基础规则，包括命名规范、缩进格式、注释要求等通用内容统一，降低跨项目开发的适配成本
  • 单个项目若存在特殊风格要求，需明确写入项目README的贡献指南章节，所有参与项目开发的人员可直接查询
• 本地提交前置校验，提前解决问题
  • 本地配置pre-commit钩子，提交代码前自动执行格式化+风格校验，将风格问题拦截在本地提交阶段，无需等到MR环节被打回

MR审查是否应当包含代码风格检查的通用做法 #

通用业界实践的结论是：人工MR审查环节不应该包含可自动化校验的代码风格类问题，但代码风格合规是MR合入的必要前置条件，正确的流程设计为：

所有可通过自动化工具校验的风格规则，全部交给CI流水线自动执行，校验不通过的MR直接无法进入人工评审环节。人工MR审查仅聚焦代码逻辑正确性、架构合理性、业务实现匹配度、安全漏洞等无法通过自动化工具批量校验的内容。
若团队暂时不具备自动化校验的条件，需要人工检查风格的，也需要提前将规则公开透明同步给所有开发者，禁止评审人按照个人主观喜好提出风格要求。

内容的提问来源于stack exchange，提问作者user17066209