idea 中 findBugs 插件的 詳細配置

參考

https://my.oschina.net/viakiba/blog/1838327 

http://findbugs.sourceforge.net/manual/index.html

界面以下

General

這一欄總共有五項

1.Compile affected files before analyze   在分析以前進行編譯

2. Analyze affect files affter comlplie 在變更的文件編譯以後 分析 自動 

3. Analyze affect files after auto make 在自動Make以後分析變更的文件 自動

4. Run analyze in background  在後臺分析，不顯示進度條窗口

5. Active toolwindow on run   按鈕是否展現

下面的Plugins 點擊加號 添加以下插件

fb-contrib 是 findBugs 的一個擴展的bug探測器

find Security Bugs 針對安全問題的探測

FindBugs for android 編碼安全問題針對Android。

 

Detector 探測器

Disabled detectors will not participate in the analysis.
'Grayed out' detector will run, however they will not report any result to the UI

即

禁用的檢測器將不參與分析。
「灰色」檢測器將運行，可是它們不會向UI報告任何結果。

 

Share

This setting file will be imported before the analyze is started. The current settings will be overwritten. Sonar and findbugs-idea setting file format is supported. This might primarily be a good solution to share Sonar setting file.

 

在開始分析以前，將導入此設置文件。當前的設置將被覆蓋。Sonar和FunBug理念設置文件格式是支持的。這多是共享Sonar設置文件的一個很好的解決方案。
在FunBug想法設置文件的狀況下，能夠更好地與官方解決方案共享「FunBugSig.xml」（在.IDEA項目目錄內）。

 

Report

Analysis effort 

分析級別   可選項： Minimal/default/Maximal

Minimum rank 

配置的錯誤級別 數字越小越嚴重 配置數字越小篩選的範圍越小

Minimum confidence

匹配具備特定錯誤等級的警告。 1 hign/2 medium /3  low 

Bad pratice

編程的壞習慣 
主要是命名問題,好比類名最好以大寫開頭,字符串不要使用等號不等號進行比較,可能會有異常最好用try-catch包裹的代碼,方法有返回值但被忽略等等,這些若是不想改能夠直接忽略.

Malicious code vulnerability

惡意代碼漏洞 
聽起來很嚇人呀,主要是一些屬性直接使用public讓別的類來獲取,建議改成private併爲其提供get/set方法. 
還有一些public的靜態字段,可能會被別的包獲取之類的. 
這些也須要根據項目具體狀況來,我的意見,在有的不重要類,有時直接公開使用屬性,可能更爲便捷.若是你認爲這些不須要修改,徹底能夠忽略.

correctness

代碼的正確性 這一項應該算是最重要的了 

主要是沒有對變量進行不爲空斷定,在特殊狀況可能發生空指針異常.

performance

性能 

主要是一些無用的代碼,好比聲明瞭沒有用到的屬性等等

security

安全

Dodgy code

糟糕的代碼 

·好比一個double/float被強制轉換成int/long可能會致使精度損失,一些接近零的浮點數會被直接截斷,事實上咱們應該保留. 

這裏順便提一點,這兩天看了《app研發錄》,在規範代碼,儘可能規避錯誤這方面我也有了一些收穫. 

在類型轉換的時候,咱們應該爲類型轉換提供一個安全的轉換方法,由於咱們永遠不會知道,咱們的app在用戶手裏會發生什麼,因此咱們要儘量的去減小這種發生錯誤的可能.

·好比使用switch的時候沒有提供default。

·多餘的空檢查，就是不可能爲空的值，增長了不爲空判斷，這是沒有必要的。屬於代碼冗餘

·不安全的類型轉換等等。 

這項太多了，就不一一列舉了。

Experimental

實驗 （參考 https://blog.csdn.net/jdsjlzx/article/details/21472253/）

1.LG: Potential lost logger changes due to weak reference in OpenJDK (LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE)
OpenJDK的引入了一種潛在的不兼容問題，特別是，java.util.logging.Logger的行爲改變時。它如今使用內部弱引用，而不是強引用。–logger配置改變，它就是丟失對logger的引用，這本是一個合理的變化，但不幸的是一些代碼對舊的行爲有依賴關係。這意味着，當進行垃圾收集時對logger配置將會丟失。例如：
public static void initLogging() throws Exception {
 Logger logger = Logger.getLogger("edu.umd.cs");
 logger.addHandler(new FileHandler()); // call to change logger configuration
 logger.setUseParentHandlers(false); // another call to change logger configuration
}
該方法結束時logger的引用就丟失了，若是你剛剛結束調用initLogging方法後進行垃圾回收，logger的配置將會丟失（由於只有保持記錄器弱引用）。
public static void main(String[] args) throws Exception {
 initLogging(); // adds a file handler to the logger
 System.gc(); // logger configuration lost
 Logger.getLogger("edu.umd.cs").info("Some message"); // this isn't logged to the file as expected
}
2.OBL: Method may fail to clean up stream or resource (OBL_UNSATISFIED_OBLIGATION)
這種方法可能沒法清除（關閉，處置）一個流，數據庫對象，或其餘資源須要一個明確的清理行動。
通常來講，若是一個方法打開一個流或其餘資源，該方法應該使用try / finally塊來確保在方法返回以前流或資源已經被清除了。這種錯誤模式基本上和OS_OPEN_STREAM和ODR_OPEN_DATABASE_RESOURCE錯誤模式相同，可是是在不一樣在靜態分析技術。咱們正爲這個錯誤模式的效用收集反饋意見。

Multithreaded Correctness

多線程問題

DL_SYNCHRONIZATION_ON_BOOLEAN
Synchronization on Boolean could lead to deadlock
該代碼同步一個封裝的原始常量，例如一個Boolean類型
private static Boolean inited = Boolean.FALSE; ... synchronized(inited) { if (!inited) { init(); inited = Boolean.TRUE; } } ...
因爲一般只存在兩個布爾對象，此代碼多是同步的其餘無關的代碼中相同的對象，這時會致使反應遲鈍和可能死鎖

DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE
Synchronization on boxed primitive could lead to deadlock
該代碼同步一個封裝的原始常量，例如一個Integer類型。
private static Integer count = 0; ... synchronized(count) { count++; } ...
因爲Integer對象能夠共享和保存，此代碼多是同步的其餘無關的代碼中相同的對象，這時會致使反應遲鈍和可能死鎖

DL_SYNCHRONIZATION_ON_SHARED_CONSTANT
Synchronization on interned String could lead to deadlock
同步String類型的常量時，因爲它被JVM中多個其餘的對象所共有，這樣在其餘代碼中會引發死鎖。

I18N

國際化

 

推薦閱讀

FindBugs 規則整理

FindBugs：簡介與使用
FindBugs 規則整理：CORRECTNESS
FindBugs 規則整理：Bad Practice
FindBugs 規則整理：Style & Dodgy
FindBugs 規則整理：Malicious Code Vulnerability
FindBugs 規則整理：Security & Experimental
FindBugs 規則整理：Performance

FindBugs 規則整理：Multithreaded Correctness
FindBugs 規則整理：Internationalization

 

https://blog.csdn.net/jdsjlzx/article/details/21472253/