【正文】 實例報告一個缺陷，指定 bug 的類型（我們將在后面詳細討論）和其優(yōu)先級。在 bug 中加入類、方法和源代碼會提供很大方便，這樣用戶就知道在什么地方修復這個問題。 編寫了代碼后，需要創(chuàng)建一個特別打包的 JAR 文件，F(xiàn)indBugs 將它識別為插件程序 JAR。清單 9 顯示了我用來創(chuàng)建這個 JAR 文件并將它拷貝到正確位置的編譯腳本：清單 9. 打包 FindBugs 檢測器的腳本 property name= value=C:\apps\/property target name=build jar destfile= fileset dir=bin/ fileset dir=src/ zipfileset dir=etc includes=*.xml prefix=/zipfileset /jar copy file= todir=${}/plugin / /target這段代碼創(chuàng)建一個包含源文件、類文件、 和 的 JAR 文件。清單 10 和 11 顯示了這兩個 XML 文件的內容：清單 10. 的內容 FindbugsPlugin Detector class= speed=fast / BugPattern abbrev=CBGL type=CBG_UNPROTECTED_LOGGING category=PERFORMANCE / /FindbugsPlugin對于每一個新的檢測器，在 文件中增加一個 Detector元素和一個 BugPattern元素。 Detector元素指定用于實現(xiàn)檢測器的類以及它是快速還是慢速檢測器。在 UI 中查看檢測器時就會用到 speed 屬性，如圖 1 所示。speed 屬性的可能值有 slow、moderate 和 fast。 圖 1. 配置檢測器 UIBugPattern元素指定三個屬性。 abbrev屬性定義檢測器的縮寫?？s寫用于標識用命令行客戶運行時檢測到的缺陷。可以用同一個縮寫將幾個相關的檢測器組織到一起。. type屬性是惟一標識符，有兩個用途。在使用 Ant 版本或者命令行版本的 FindBugs 且輸出格式設置為 XML 時，用 type屬性標識問題。 type屬性也是在檢測器的 Java 代碼中指定的，用以創(chuàng)建缺陷的正確類型。注意這里列出的類型與在 清單 8中第 39 行使用的名字相匹配。. category屬性是枚舉類型。它是以下類型中的一種： CORRECTNESS：一般正確性問題 MT_CORRECTNESS：多線程正確性問題 MALICIOUS_CODE：如果公開給惡意代碼，有可能成為攻擊點 PERFORMANCE：性能問題 文件就是這些了。清單 11 顯示了 文件的內容：清單 11. 的內容 MessageCollection Detector class= Details ![CDATA[ p This detector finds logs statements that aren39。t contained in an iflogging block. It is a fast detector. ]] /Details /Detector BugPattern type=CBG_UNPROTECTED_LOGGING ShortDescriptionFound unprotected logging/ShortDescription LongDescriptionFound unprotected logging in {1}/LongDescription Details ![CDATA[ p This method logs without first checking that logging is enabled。 for example ... more text omitted... ]] /Details /BugPattern BugCode abbrev=CBGLFound unprotected logging/BugCode /MessageCollection 文件由三個元素組成： Detector、 BugPattern和 BugCode。 檢測器的 class屬性應當指定檢測器的類名。 Details元素包含檢測器的簡單 HTML 描述，因而應當包含在 CDATA部分中。UI 使用這些描述，如圖 2 所示： 圖 2. FindBugs UI 突出顯示未監(jiān)護日志檢測器BugPattern元素類似于在 中定義的 BugPattern元素。需要 type屬性，并且它應當匹配在 和在檢測器的 Java 代碼中使用的相同惟一標識符。 BugPattern包含三個影響有關檢測器的信息在 UI 中顯示方式的元素： ShortDescription、 LongDescription和 Details——它們的意義都是相當直觀的。 在 UI 中關閉 View Full Descriptions 時，使用 ShortDescription。同樣，在啟用 View Full Descriptions 時，使用 LongDescription?？梢允褂米⑨專╝nnotation）將信息從缺陷檢測器的 Java 代碼中傳遞給完全描述。在描述中，用 {0}表示第一個注釋、 {1}表示第二個注釋等來指定變量。在運行時，如果發(fā)現(xiàn)缺陷，附加在缺陷實例上的注釋將替換到描述中。注意在 清單 8的第 40 行，類和方法注釋添加到了 BugInstance上。類注釋在位置 0，方法注釋在位置 1。更多細節(jié)請查看 BugInstance上的不同 add*()方法。 與前面一樣， Details元素應當在 CDATA部分中包含一個 HTML 描述。圖 2 顯示了我們的檢測器細節(jié)的一個例子。View Full Descriptions 已經打開。 在使用 By Bug Type 選項卡時，UI 使用 BugCode元素。這個元素的文字在樹中作為紅色節(jié)點出現(xiàn)，如 圖 2所示。公共檢測器共享同一個縮寫，因此 BugCode元素必須用元素的屬性指定這個縮寫。 創(chuàng)建了這兩個 XML 文件后，我們現(xiàn)在就可以打包完整的 JAR 了。在編譯了 JAR 并將它放到 FIND_BUGS_HOME\plugin 目錄中后，就可以測試新的檢測器了。特定于應用程序的缺陷檢測器FindBugs 會是您的裝備庫中一件有用的工具。但是，像所有工具一樣，必須知道如何使用它。不過，靜態(tài)分析工具應作為單元 / 系統(tǒng)測試和代碼審查的補充。除了其改進代碼質量的作用，F(xiàn)indBugs 還有很多特定于應用程序的用法，我鼓勵讀者去探索它們。例如，可以編寫一組檢測器，它們可以查找新手容易出現(xiàn)的問題。也可以編寫檢查代碼是否符合小組規(guī)則的檢測器。也許您正在構建一個框架，并且需要保證包中的所有類都有零參數(shù)的構造函數(shù)、或者所有帶下劃線前綴的字段都有 getter 而沒有 setter。也許可以編寫一組檢測器，它們驗證 J2EE 代碼遵守適當?shù)南拗?，如不?chuàng)建 Thread或者 Socket。 未監(jiān)護日志例子中的小組還有捕獲異常的問題。值得稱贊的是，他們沒有簡單忽略這些異常，相反，他們讓它們打印自己的堆棧跟蹤，這對于編譯和調試應用程序很好，但是對于部署來說這不是很理想——特別是當可能有數(shù)千個異常時。（當然，如果應用程序拋出數(shù)千個異常，您的問題就比大的日志文件要嚴重得多了，但是姑且容許我為了說明問題而這樣說。）小組需要一個檢測器來找出代碼中捕獲異常并要求打印其堆棧跟蹤的地方。這樣他們就可以改變代碼，將異常改為傳遞給日志框架。我創(chuàng)建了另外一個有趣的未監(jiān)護日志檢測器。這個檢測器用于尋找代碼中所有在監(jiān)護子句以外生成要記錄消息的地方——如果使用了行為有些特別的 toString，這會是一個非常常見的問題，并且代價有可能相當昂貴。 回頁首結束語不管是剛接觸 FindBugs 還是已經熟悉它了，我鼓勵您用自己的特定于應用程序的檢測器進行試驗。同時，我希望本文提供如何實現(xiàn)自定義檢測器的簡潔例子，并鼓勵您將這些思路應用到小組的特定情況中去。FindBugs，第 2 部分: 編寫自定義檢測器FindBugs，第 2 部分: 編寫自定義檢測器