本期内容分为五个部分，阅读时长预估7分钟：

使用背景

CheckStyle使用意义

CheckStyle安装与使用

CheckStyle检查配置示例

落地使用情况及效果

使用背景

玩物得志目前还处在一个狂奔业务的时期，开发一般都全力支撑业务的快速奔跑，没有太多的时间专门优化代码或者说没有一个编码规范约束开发同学写的代码，导致早期很多业务代码的可读性及可维护性比较差。

随着团队人员规模的增大，不断有新人加入及每个人的编码经验、代码习惯风格不同，很难靠口头讲来规范团队的代码规范。

能否有一个工具从一开始写代码就要求开发人员遵守编码规范？

编写整洁优雅的代码，减轻CodeReview工作量，减少后续不断重构糟糕冗余的代码，自动化代码规范的检查过程？

它就是CheckStyle！

什么是CheckStyle

简单的说就是帮助Java程序员编写符合代码规范的工具。

它支持高度可配置的各种检查规则，进行自动化的检查，不符合代码规范的地方会有红色波浪线提醒，鼠标箭头移上去会有相应的提示，简单易用！

编码常见的问题

CheckStyle支持100多项代码检查规则，下面整理了我们平时编写代码中常见的不规范问题如下：

Import语句(无用的导入，多余导入使用'.*')

嵌套层数太多，可读性、可维护性太差(if嵌套层数过多，try catch嵌套层数过多)

魔术数字

命名不规范(Static变量名\常量名\参数名\方法名\包名\类名\接口名)

方法、类行数太多导致可读、可维护性太差

方法参数个数过多

方法分支复杂度、圈复杂度过多

类或接口声明部分顺序没按照Java语言编码规则

空catch块，if else语句没有使用大括号等

编码细节问题：如检查是否在long类型定义了大写的L，字母小写l和数字1很相似

CheckStyle使用意义

遵从共同的编码规范，编写出易于阅读和维护的代码，减少Bug产生的可能性

自动化代码规范的检查过程，提升代码质量，减轻CodeReview工作量，提升研发效能

形成团队整体良好的编码习惯，减少后续因糟糕冗余代码导致的不断重构的工作量，提升研发效能

CheckStyle安装与使用

CheckStyle插件安装

点击Preferences，搜索框里搜索plugins，点击Plugins，搜索CheckStyle找到CheckStyle-IDEA插件，安装并启用

IDEA CheckStyle插件生效

点击Preferences，搜索框里搜索Inspections，点击Inspections，搜索CheckStyle找到CheckStyle勾选上，建议右下角的Severity配置成Error级别

CheckStyle配置文件

通过下方途径下载CheckStyle配置文件，CheckStyle的检查有error、warn、info三种级别

公众号内回复【checkstyle】获取配置文件

copy到应用包的目录下

添加CheckStyle配置文件

点击Preferences，搜索框里搜索CheckStyle，按如下步骤添加配置文件

运行查看执行效果

支持当前文件、整个工程及分支增量更改文件的checkStyle检查，检查效果如下：

Checkstyle引入到maven构建中

为什么使用maven的checkstyle插件，主要可以约束打的包符合代码规范。

如果代码不规范连包都打不起来，因为插件配置到了maven的生命周期里(一开始可能不符合规范的代码很多，如果来不及全部改完建议暂时先注释掉引入的checkstyle插件来打包，后续修改完再去掉注释)

主 Pom包中引入 maven-checkstyle-plugin

org.apache.maven.pluginsmaven-checkstyle-plugin3.0.0packagechecktruetrueUTF-8wwdz-checkstyle.xmlcom.puppycrawl.toolscheckstyle8.0

执行命令:

mvn checkstyle:checkstyle

执行检查结果：

CheckStyle引入注意的问题

检查工程中返回给前端或者客户端使用的VO类中的变量，如果不符合驼峰命名规范，扫描出来不能直接更改，因为这些变量前端做展示使用，需要前端和客户端兼容更改。建议先使用 //cs:off //cs:on 忽略校验，后续杜绝此类问题的产生

提供Http请求的传参命名不符合驼峰命名规范，扫描出来不能直接更改，需要客户端或前端做兼容更改。建议先使用//cs:off //cs:on 忽略校验(如下图所示)，后续杜绝此类问题的产生

提供Http请求的传参个数过多，不能直接更改，需要调用的客户端或前端兼容更改。建议先使用//cs:off //cs:on 忽略校验，后续杜绝此类问题的产生

一开始引入CheckStyle可能不符合规范的改动点很多，可以针对增量修改、新增文件做CheckStyle，本地代码在commit之前可以针对这次提交的增量代码进行CheckStyle检查

(其实在编写代码的时候有不符合规范的也会实时红色波浪线提醒，鼠标移动上去就有相应的提示！)

CheckStyle检查配置示例

CheckStyle的所有检查项见官方文档：https://checkstyle.sourceforge.io/checks.html，下面针对应用中常见的CheckStyle检查不通过的做下说明：

嵌套层数

try catch嵌套层数

默认是一层，可根据实际配置(建议不超过两层)，嵌套层数越多可读性越差，后续不便于代码维护

if嵌套层数

默认是一层，可根据实际配置(建议不超过两层)，if 嵌套层数越多可读性就越差，后续不便于代码维护

如下代码中的多层嵌套，可通过if return 编码方式减少if嵌套层数

Import语句

必须导入类的完整路径，即不能使用*导入所需的类

检查结果

检查是否导入不必显示导入的类

检查是否导入的类没有使用

检查结果

复杂度

魔术数字

代码中最常见的问题，改为使用常量定义替代

命名不规范

常量命名规范配置

在编写代码过程中如果不符合常量命名规范有如下提示：

方法名命名规范配置

参数命名规范配置

方法参数个数

局部变量名规范

局部变量不规范提示：

成员变量

不规范提示：

UpperEll

代码行数限制

如下限制方法行数不能超过60行，类行数不能超过1200行，一个文件的行数不能超过1500行

行数过多提示如下：

方法参数限制

声明顺序检查

根据Java编程语言的编码规约，一个类或接口的声明部分应当按照以下顺序出现：

类(静态)变量：首先应当是public类变量，然后是protected类变量，再次是package类变量(没有访问标识符)，最后是private类变量

实例变量：首先应当是public类变量，然后是protected类变量，再次是package类变量(没有访问标识符)，最后是private类变量

构造器

方法

例如下图中静态属性定义顺序错误的提示

空catch块

异常catch，要做些error日志关键信息打印返回错误对象或者抛异常，检查不符合此规范的示例如下：

if else 花括号检查

落地使用情况及效果

目前CheckStyle已在用户、订单、商家、社区、支付等多个组落地使用。作者所在用户组经过一周CheckStyle检查不通过的历史代码修改优化，及新提交的CodeReview代码前必须经过CheckStyle检查，组内代码整洁度及可读性有了很明显的提升，CodeReview的工作量也比之前减轻了很多。

有了CheckStyle这个代码规范利器，组内研发效能和代码质量又有了进一步的提升！

点击

“阅读原文”查看更多精彩