在ANT的build.xml文件中添加CheckStyle任務的步驟如下：
1. 將checkstyle-all-3.1.jar拷貝到項目的LIB目錄；
2. 建立配置文件；
3. 聲明CheckStyle任務：
| ＜taskdef resource="checkstyletask.properties" classpath="${lib}/checkstyle-all-3.1.jar"/＞ |
4. 建立CheckStyle任務：
| ＜target name="checkstyle"＞ ＜checkstyle config="${config}/sun_checks.xml"＞ ＜fileset dir="${src}" includes=" **/*.java" /＞ ＜/checkstyle＞ ＜/target＞ |
2.4. 定制CheckStyle
CheckStyle的執行基于XML配置文件，它的主要組成部分是：
·Module：整個配置文件就是一棵Module樹。根節點是Checker Module。
·Properties：它來決定一個Module如何進行檢查。每個Module都有一個默認值，如果不滿足開發需求，可以設定其它的值。
下面是一個示例：
| ＜module name="MethodLength"＞ ＜property name="max" value="60"/＞ ＜/module＞ |
它表示，如果方法或者構造函數的長度超過60行，CheckStyle就會報錯。而默認值是150行。
以下是一段CheckStyle對于Maven項目源文件的檢查報告：
| Method 'createExpression' is not designed for extension - needs to be abstract, final or empty. 91 Unable to get class information for JellyException. 91 Line has trailing spaces. 93 Line has trailing spaces. 104 Method 'evaluate' is not designed for extension - needs to be abstract, final or empty. 113 Parameter context should be final. 113 Line has trailing spaces. 130 Method 'getExpressionText' is not designed for extension - needs to be abstract, final or empty. 131 Line has trailing spaces. 134 Line has trailing spaces. 135 Method 'toString' is not designed for extension - needs to be abstract, final or empty. 137 Method 'isSupportAntVariables' is not designed for extension - needs to be abstract, final or empty. 156 Method 'setSupportAntVariables' is not designed for extension - needs to be abstract, final or empty. 168 Parameter supportAntVariables should be final. 168 'supportAntVariables' hides a field. 168 Method 'isValidAntVariableName' is not designed for extension - needs to be abstract, final or empty. 183 Parameter text should be final. 183 |
一般情況下，與IDE集成在一起使用的時候，點擊出錯的條目，可以跳轉到相應的代碼。
三、CheckStyle的最佳實踐
3.1. Sun’s Code Conventions的修改
在CheckStyle的最新發布版本中，有一個對于Sun的Java編碼規范的配置文件信息。但是，其中有很多條目并不一定符合項目開發的需要。就算是對于很多優秀的開源項目，按照這個規范來進行檢查，也會出現成千上萬的錯誤。
下面提出的一些修改意見，是從實際項目執行過程中總結出來的，可以作為大家的參考。我們以CheckStyle3.0配置文件的順序來介紹：
1. 去除對于每個包都有一個package.html文件的限制；
| ＜!--＜module name="PackageHtml"/＞--＞ |
2. 修改對于JavaDoc Comments的限定：對于很多使用Code Generator的項目來說，需要將手寫代碼與生成代碼、單元測試代碼的檢查分開進行；
3. 修改對于體積大小的限制：目前，很多顯示器都是17寸，而且打印方面的限制也比以前有所改善，同時，由于代碼中Factory等模式的運用，以及有意義的方法名稱等約定，默認每行代碼的長度（80）是遠遠不能滿足要求；對于方法長度等等，也應該根據項目情況自行決定：
| ＜module name="FileLength"/＞ ＜module name="LineLength"＞ ＜property name="max" value="120"/＞ ＜/module＞ ＜module name="MethodLength"＞ ＜property name="max" value="300"/＞ ＜/module＞ ＜module name="ParameterNumber"/＞ |
4. 修改對于Throws的的限制：允許Throws Unchecked Exception以及Throws Subclass Of Another Declared Exception。
| ＜module name="RedundantThrows"＞ ＜property name="allowUnchecked" value="true"/＞ ＜property name="allowSubclasses" value="true"/＞ ＜/module＞ |
5. 修改成員變量的可視性：一般情況下，應該允許Protected Members以及Package Visible Members。
| ＜module name="VisibilityModifier"＞ ＜property name="protectedAllowed" value="true"/＞ ＜property name="packageAllowed" value="true"/＞ ＜/module＞ |
3.2. CheckStyle應用的最佳實踐
采用CheckStyle以后，編碼規范的檢查就變得及其簡單，可以作為一項切實可行的實踐加以執行。
一般情況下，在項目小組中引入CheckStyle可以按照下面的步驟進行：
1． 強調Code Review與Code Conventions的重要作用；
2． 介紹CheckStyle；
3． 初步應用CheckStyle：參照CheckStyle附帶的配置文件，酌情加以剪裁，在項目的Ant配置文件中，添加CheckStyle任務，可以單獨執行；
4． 修改、定型CheckStyle的配置文件：按照基本配置文件執行一段時間（2～3周），聽取開發人員的反饋意見，修改配置信息；
5． 作為開發過程的日常實踐，強制執行CheckStyle：穩定CheckStyle的配置信息，同時將CheckStyle任務作為Build的依賴任務或者配置源碼控制系統（目前，CheckStyle可以與CVS有效集成），使得代碼在加入系統之前必須通過檢查。
同時需要指出的是，CheckStyle的有效執行需要依賴兩個條件：
·Ant的廣泛應用：CheckStyle基于Ant執行的方式比較容易，而且可以在項目內容形成一致的執行環境。同時，也比較容易與其它任務，例如Build等發生關聯。
·IDE Format Code的強大功能：由于CheckStyle本身并沒有提供很強大的Code Format等功能，因此，需要借助IDE的幫助，從而使得在發生錯誤的時候，可以很容易的進行修復。目前，主流的Java IDE都提供了這方面的功能，IDEA在這方面尤其突出。它提供的統一、可定義的Code Format Template（項目小組內部可以使用統一模板）以及方便的快捷鍵功能(Ctrl+Alt+T：Format Code, Ctrl+Alt+O：Optimize Import等)。
四、結論
利用CheckStyle可以方便的對于編碼的Code Conventions進行檢查，同時，也有效地減少了Code Review的工作，使得Reviw人員的精力更多的集中到邏輯和性能檢查
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
