本期內容分為五個部分，閱讀時長預估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這個代碼規范利器，組內研發效能和代碼質量又有了進一步的提升！

點擊

“閱讀原文”查看更多精彩

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的玩物得志Java笔试题_代码规范利器-CheckStyle的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。