Java 项目如何做代码风格的统一管理

[codingbody]

Java 项目如何做代码风格的统一管理，我看大多开源项目使用的是 checkstyle 。

我了解 checkstyle 只是可以检查出不符合要求的代码，那么如何快速 format 这些不符合要求的代码呢？

各位在工作中是如何实践的呢？我期望的是可以配合 maven 或 gradle 构建工具达到 check 、format 两个目的。这样方便团队成员更容易遵守规范，通过 IDE 插件的话同步成本比较高。

[zhenjiachen]

格式化插件我只找到 spring 的 format 插件，但是这个插件代码样式是写死的，只能按照他们的来，不能自定义。

[petercui]

IDEA 有 Alibaba code guide 和 save action

格式化代码的话，Gradle 和 maven 有插件 spotless

[guisheng]

不是有 Google 的 check style 文件么 gradle 有插件可以配置，提交代码可以增加 git 强制检查，还有 format

[admin7785]

提交前 checkstyle ，不符合要求了，不应该是代码 owner 自己修改吗？为什么要自动 format ？

[hpu423]

不建议搞代码风格管理，最好搞成屎山，被裁的时候还能有点话语权

[xaplux]

一般公司项目很少强制代码风格吧，统一使用一套 code style 文件就行，更多的是开源项目会强制要求

[Dragonphy]

IDEA 自带的就够了，前端才会严格限制代码风格，不然代码乱飞

[Niphor]

java 这方面实在有点弱，用各种插件，还不如直接把 idea 的配置放项目里...
小公司就不要搞了，没人会来遵守的

[dk7952638]

@hpu423 企业级理解

[zr8657]

你是技术经理 /项目经理吗，不是的话别皮，老老实实写好自己那份代码

[VeryZero]

查出来让他自己改啊，自动 Format 不怕形成依赖吗？对团队提升意义不大吧

[cedoo22]

@hpu423 之前遇到一个老 6 ， 代码离开他 3 天就各种异常， 当时我们还嘲笑他技术， 到现在才知道 差距。

[excitedXXX]

统一一下 code style 防止代码冲突就可以了= =

[TaylorBu]

阿里的 P3C-PMD ，可以集成到 Gitlab 上，每次代码提交检查规范

[MarioLuo]

在公司内部写了一个 IDEA 插件，定义了代码风格文件，安装插件后会自动设置代码风格，并且在代码提交时候，每次默认勾选 `Code format` `Optimize import`,

[LeegoYih]

搭一个 sonar 扫描代码呗，配置一下规范，分数低于 90 分不允许发布

[zhenrong]

Sonar + PMD 自动扫描，Gerrit 做 code review 不通过没法 MR 保证治的服服帖帖。问题在于开发团队的整体素质的跟得上吗，愿意花多少时间和多大代价绣花。

[odirus]

刚好做过类似的事情，我们通过 Checkstyle 来实现格式检查，但如果格式不正确怎么快速格式化呢？因为我们这边基本用的 IDEA 社区版，经过调研最终我用的 editorconfig 配置文件来实现，下面细说：
1 ）将统一的 IDEA 风格导出到 editorconfig 配置里面去（不要怀疑，可以这样玩的，是以 "ij_java" 开头的配置）；
2 ）然后想办法写入到大家的项目目录下，当打开项目时 IDEA 会优先使用当前项目 editorconfig 里面的配置，IDEA 下面也会提示 "one or more code style options are overriden by By EditorConfig"，这样就生效了；
3 ）那怎么让这个配置文件写入到大家的项目目录下呢，我们开发了一个 IDEA 插件，只要大家安装了，启动项目时一旦检测到公司的项目就自动写入配置文件或者更新配置文件；
综上，需要用到两款插件（ Checkstyle + 自研）、editorconfig 就可以实现了，如果喜欢折腾的话就在自研插件里面集成 Checkstyle 代码，代码是开源的。

[Red998]

自己写就统一 团队开发 不太可能统一、每个人的开发风格都不一样

[humpy]

代码自动格式化，我是这么做的：

1. 用 eclipse 调出一个组内统一的代码格式配置；
2. 将相关配置文件打包成一个 jar 包，方便统一使用更新；
3. java 项目使用 spotless-maven-plugin 做代码格式自动化应用，并将插件 task 绑定到 process-sources 这个 phase ，这样每次 maven 编译前，都会自动做代码格式化；
4. 使用 git pre-commit 钩子，在每次 commit 之前，执行 maven spotless:apply 命令，自动格式化代码；
5. 使用 maven-git-hook-plugin ，在 initialize phase ，初始化 .githooks 钩子。

（到这一步了，也就是新拉下来一个项目，只要随便执行一个 maven 指令，就能配置好本地的代码格式化环境，但是好多同事开发完全依赖 idea ，而在 idea 里运行项目，默认不会走正常的 maven 编译流程，触发不了配置的 maven 格式化任务。为了解决这个问题，我们使用 maven archetype 创建项目脚手架，生成的新项目的时候修改了 .idea/workspace.xml 文件，增加了一个执行 maven formatter 的 before lauch action ，这样从 idea 启动应用，也会每次都执行代码格式化了。）

到此基本上一套自动格式化代码的流程就算实现了。同时，对喜欢随时自己做格式化操作的朋友，idea 可以安装 Adapter for Eclipse Code Formatter 插件，使用上面（ 1 ）步的格式化配置，替换掉 idea 自带的格式化工具。

ps. 做代码格式化有个容易被忽略但很重要的点，是 import 的顺序，这个一定要统一。spotless-maven-plugin 支持使用 eclipse 的 importorder 配置，我们现在是这么弄的：

0=java
1=org
2=com
3=我们公司的 package 前缀
4=
5=\#

[NGXDLK]

你要不架把刀到每个人脖子上，要不代码不规范不让合代码
除了强制执行，否则下面的人听不听还另说

[ryougifujino]

前端 ESLint 和 Prettier 几乎成了标配了，Rust 也有 rustfmt ，Java 这方面看起来还没达成共识（

[codingbody]

@humpy #20 spotless-maven-plugin 可以做到把未使用的 import 移除嘛

[xuyang2]

formatter 代替不了 code review
代码风格已经是很细枝末节的东西

https://www.morling.dev/blog/the-code-review-pyramid/
https://www.morling.dev/images/code_review_pyramid.png

[winix]

https://github.com/google/google-java-format

[iamqida]

我司是制定了 eclipse code formatter 规则，配合 saveaction

[humpy]

@codingbody #23 可以的，你可以配置个 demo 项目试一下。https://github.com/diffplug/spotless

<java>
<includes>
<include>src/main/java/**/*.java</include>
<include>src/test/java/**/*.java</include>
</includes>
<importOrder>
<file>${build-utils.format.importorder}</file>
</importOrder>
<removeUnusedImports/>
<eclipse>
<file>${build-utils.format.java}</file>
</eclipse>
</java>

[humpy]

@codingbody 你们团队还注重 code style ，挺好的，现实里遇到的好多开发，根本不在乎代码格式这些东西，更别说代码的美感了，那些代码看着都糟心。

要做这件事，我建议就三个点：

1. 拍板一个代码格式标准（越讨论越没完没了，直接拍板）；
2. 用 spotless-maven-plugin 或者类似的工具，通过 git pre-commit 钩子在开发者提交代码时自动做一下格式化（减少开发负担和抵触）；
3. git 中心仓库在代码推送时，对代码做一下 mvn spotless:check ，不通过的不让入库（防止钻空子）。

[uselessVisitor]

很难，就算你搞了他们也不会按照你的来，idea 中一个类里面警告 100+装作没看见，还在早会上推行在 service 层直接返回 Result （统一封装的返回给前端的）。写好自己的代码得了

[tianyu94]

我们用的 prettier-maven-plugin ，搭配 git hooks ，格式不合法直接不让提交；当然 hooks 可以绕过，所以流水线还有一个 lint stage

当然也有缺点，如果项目非常大就比较慢。一般项目格式化和检查速度还行

[tianyu94]

@tianyu94 然而这样仅仅是解决“格式”规范；一些编码上的问题，逻辑问题、性能问题等还是得靠工程师经验或者实施代码评审

[hpu423]

@dk7952638 过来人都懂，企业都不按照劳动法赔偿，要学会保护自己

[nothingistrue]

国内还是别搞代码规范了。一管就过——一刀切的代码风格会严重挤占正常的开发时间甚至还会制造为了让工具零报错而产生的诡异代码。一松就乱——偶尔不检查一次后面就只能都不检查了。

代码风格跟代码一样，要想一直保持高质量，需要持续改善，需要：
一，定义一个强制性但最低限度的基础代码风格用于自动化格式，这个通常是要 IDE 插件自动格式化，在 maven/gradle 构建阶段自动格式化会导致开发阶段没法所见即所得。
二，在代码合并阶段，除了自动化检查代码格式工具（ Git hook 、maven/gradle checkstyle 插件）外，还要附加人工评审，对于不适合让工具自动处理的格式化，进行人工格式化。
三，每隔一段时间，停止所有开发，进行一次集中的总体代码优化。