前言

最近換了新的公司，面對新的程式碼大家都有不同的熟悉過程和方法。在我的角度來說，利用程式碼檢測工具，可以更直接地去熟悉程式碼邏輯和業務邏輯，表現得自己去程式碼質量很有追求，最重要當然是在公司的任務管理工時上面顯得自己積極向上啦。不過在修改程式碼之前，你要根據專案的分工、明確在公司的定位，不然會造成一些不愉快的事情，但是總的來說我們還是對程式碼質量有追求的！

我們首先要知道Android Studio安裝外掛步驟。

Android Lint

Lint是Android Studio提供的一個程式碼檢測工具，開發者通過它不用寫測試程式碼，就可以發現和糾正問題，優化程式碼結構。

Lint 的使用路徑：
工具欄（或右擊package）-> Analyze -> Inspect Code

待分析完畢後，我們可以在Inspection欄目中看到檢查的結果

Lint被檢測到的問題，都有描述基本資訊並指明相應的嚴重性級別，我們可以根據問題的嚴重程度進行處理優化。Android Lint內建了很多lint規則，共可以分為以下幾類：

• correctness 正確性
• Security 安全性
• Performance 效能
• Usability 可用性
• Accessibility 可訪問性
• Internationalization 國際化

自定義Android Lint的檢查提示

在xml編寫佈局的時候，例如TextView，我們常常會直接將text字串值直接寫在xml上面，還是在textSize屬性上寫上sp值，然而，IDE會有相關的提示：

看到這個提示，大家覺得級別過低不會太多理會，其實這並不是一個好的編碼習慣，所以我們可以通過更改對應的severity等級來更改提示的等級，如： 預設hardcode的severity等級為warning，我們修改hardcode的severity等級為error，那麼在存在硬編碼時候將會以error等級提醒我們：

修改完成後，我們可以看到text提示使用紅色錯誤的波浪線標記了，如下圖，但是我們這個修改是提示，我們看上端檔案並沒有標錯，所以是不會影響程式執行的。

Lint還有很多自定義的設定，大家有興趣可以看一下這篇文章自定義 Lint 規則如何幫助開發者，然後去嘗試一下。

另外由於lint的規則過多，我們沒有必要每一個都要知道，我們需要在檢測分析後，能區分出這個是屬於什麼型別的錯誤和嚴重程度，根據給出的錯誤提示，或直接使用搜索引擎/神器 stackoverflow進行對應的錯誤搜尋並解決。

FindBugs

FindBugs使用靜態分析方法為出現bug模式檢查Java位元組碼。FindBugs基本上只需要一個程式來做分析的位元組碼，所以這是非常容易使用。它能檢測到常見的錯誤，如NullPointException,多執行緒同步問題等。

FindBugs 的使用路徑：
工具欄（或右擊package）-> FindBugs -> Analyze對應目標

FindBugs支援對包級別、專案級別、模組級別、單個檔案級別、自定義範圍的Bug分析。

程式碼缺陷分類：

• Bad practice：不好的做法；
• Malicious code vulnerbility：惡意的程式碼漏洞；
• Correctness：正確性問題；
• Performance：潛在的效能問題；
• Security：安全性問題；
• Dodgy code：糟糕的程式碼；
• Experimental：實驗；
• Multithreaded correctness：多執行緒的正確性多執行緒程式設計時，可能導致錯誤的程式碼；
• Internationalization：國際化問題；

FindBugs檢測之後，當我們選中的錯誤，在右方有十分詳細的描述，我們可以根據給出的錯誤類對應的行數、方法、錯誤基礎描述、優先順序的資訊進行優化解決。

當然大家對FindBugs的錯誤描述有興趣，可以瀏覽一下FindBugs Bug Descriptions，而解決方案我們利用神器 stackoverflow

Checkstyle

Checkstyle是一個開發工具用來幫助程式設計師編寫符合程式碼規範的Java程式碼。這個工具能夠幫助你在專案中定義和維持一個非常精確和靈活的程式碼規範形式。

相信大家做過幾個不同的專案後，會發現不同的開發者有著不同的程式碼風格習慣，有的是教科書式規範，有的是像行外人般的隨心所欲。所以好的程式碼風格對開發是事半功倍的。站在一個管理者的角度，Checkstyle對整一個開發的水平管理很有幫助，曾聽說某專案管理在code review時發現程式碼不符合規範直接辭退開發。站在一個開發者的角度，一個規範的程式碼風格，看著程式碼就感覺舒暢，再聽著小歌，寫程式碼簡直就能飛起來。現實一點就是，人家看你的程式碼風格就知道你是個大神。在最近的阿里出品的Java開發手冊，得到了業內很好的響應。良好的程式碼風格讓我們的水平不斷向BAT靠近。下圖值得你擁有。

Checkstyle檢測範圍：

• javadoc註釋
• 命名規範
• 標題
• 匯入包規範
• 體積大小
• 空格
• 修飾符
• 程式碼塊
• 編碼問題
• 類設計問題
• 重複、度量以及一些雜項

Checkstyle使用步驟

1.安裝CheckStyle-IDE外掛

2.新增檢查規則檔案

3.CheckStyle-IDE 外掛使用

同樣我們可以對專案級別、模組級別、單個檔案級別進行檢測。

4.CheckStyle掃描結果

5.根據Checkstyle掃描結果對應修改
重複3.~5.部，至修改完成。

Checkstyle定製

我覺得定製屬於自己公司的checkstyle檢測規則是十分重要的。我們可以看一下Google checkstyle 檢查規則

Checkstyle檢查規則是基於XML配置檔案的，主要通過XML檔案中的module 、property、message標籤節點對檢查規則進行配置。在XML檔案中，被指定的module，都將被對應規則檢查。

1.module節點
module 主要是指檢查項，如MethodName （檢查方法命名）

module中有兩個比較重要的節點，它們分別是Checker（checkStyle配置檔案的根節點，必須存在）、TreeWalker（樹遍歷器），TreeWalker會自動去檢查指定範圍內的每一個java原始檔，TreeWalker內部會定義很多module。

module的根節點是Checker，一定要有；

2.property節點
對應module 檢查項中具體檢查屬性，如果使用預設值，property節點可以省略；

3.message節點
checkStyle檢查出來，是否打印出message訊息，message節點可以省略.

4.Checkstyle-IDE進行掃描後,讓Checkstyle不對部分程式碼進行規則檢查.
在定製好的checkStyle.xml檔案中，新增一個名為SuppressionFilter的moudle，在過濾規則檔案suppressions.xml中新增相應的過濾規則。

Checkstyle有很多玩法，有興趣的同學可以看一下Checkstyle官網資料和Github CheckStyle原始碼總而言之，Checkstyle助我們技（喪）術（心）升（病）華（狂）！

PMD

PMD（注意搜尋的關鍵字用QAPlug - PMD）是一個很有用的工具，它跟Findbugs類似，但是它不同與FindBugs檢測位元組碼，它是直接檢測原始碼。PMD也是使用靜態分析方式來發現錯誤。因此根據它們的檢測方式不同，我們可以將PMD和FindBugs結合一起使用。

PMD同樣有好多rule,且適用多種語言。如Android目前有三個規則：

Android (java)

• CallSuperFirst: Super should be called at the start of the method（檢查在Activity或Service裡的子類裡，是否在錯誤位軒呼叫父類onCreate等應該放在方法前的方法。）
• CallSuperLast: Super should be called at the end of the method（檢查一些應該在方法結束時才呼叫父類實現的情況。）
• DoNotHardCodeSDCard: Use Environment.getExternalStorageDirectory() instead of “/sdcard”（你應該用Environment.getExternalStorageDirectory()而不是硬編碼去取得擴充套件儲存目錄。）

PMD使用步驟

1.在build.gradle里加入plugin

apply plugin: 'pmd'

2.定義任務，ruleSets是需要檢查的一些規則，有興趣的同學可以看看官方定義的rule,按需來新增。

task pmd(type: Pmd) {
    source fileTree('src')

     ruleSets = [
            'java-android'
            ···
    ]
    reports {
        xml.enabled = false
        html.enabled = true
        xml {
            destination "$reportsDir/pmd/pmd.xml"  //這裡是報告產生的路徑
        }
        html {
            destination "$reportsDir/pmd/pmd.html"  //這裡是報告產生的路徑
        }
    }
}

3.Gradle執行自定義任務，在對用的路徑下找到檢測結果。

總結

其實工具和方法很多，而且很多工具和方法有重複功能，大家都可以根據需要修改和調整。另外同學覺得本篇並沒有針對常用的問題，進行分析和貼出解決方案。我個人建議大家可以在stackoverflow盡情翻閱，看看歪果仁是怎麼去交流和解決問題的。

由於本人剛入職不久的小開發，通篇是站在一個開發員工角度來描述，使用的是外掛的形式去描述使用，如果對一個公司的程式碼質量管理，可以利用Gradle配置，結合SonarQube等工具進行管理和code review。

個人習慣是，我首先用Lint應用於一些基礎檢測，再用FindBugs檢測一些潛在的Bug，PMD較少用。然而Checkstyle是需要一直使用，對程式碼風格的規範。

我們一定要清楚我們的目的，制定規範和使用規範的是為了讓團隊能一起愉快的寫程式碼，讓其他同事能簡單地對專案進行維護。