findBug 錯誤修改指南（轉載）
阿新 • • 發佈：2018-10-31
FindBugs錯誤修改指南
1. EC_UNRELATED_TYPES
Bug: Call to equals() comparing different types Pattern id: EC_UNRELATED_TYPES, type: EC, category: CORRECTNESS
解釋：
兩個不同型別的物件呼叫equals方法，如果equals方法沒有被重寫，那麼呼叫object的==，永遠不會相等；如果equals方法被重寫，而且含有instanceof邏輯，那麼還是不會相等。
解決方法：
應該改為str.toString()
2. IM_BAD_CHECK_FOR_ODD
Bug: Check for oddness that won’t work for negative numbers Pattern id: IM_BAD_CHECK_FOR_ODD, type: IM, category: STYLE
解釋：
如果row是負奇數，那麼row % 2 == -1，
解決方法：
考慮使用x & 1 == 1或者x % 2 != 0
3. NP_ALWAYS_NULL
Pattern: Null pointer dereference id: NP_ALWAYS_NULL, type: NP, category: CORRECTNESS
A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed.
4. RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
Bug: Redundant nullcheck of bean1, which is known to be non-null Pattern id: RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE, type: RCN, category: STYLE
This method contains a redundant check of a known non-null value against the constant null.
這種方法包含了一個稱為非空對空值的不斷重複檢查。
修改為：
5. SS_SHOULD_BE_STATIC
Bug: Unread field: ADDRESS_KEY; should this field be static? Pattern id: SS_SHOULD_BE_STATIC, type: SS, category: PERFORMANCE
This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.
解釋：
final成員變量表示常量，只能被賦值一次，賦值後值不再改變。
這個類包含的一個final變數初始化為編譯時靜態值。考慮變成靜態常量
解決方法：
增加static關鍵字
6. EQ_COMPARETO_USE_OBJECT_EQUALS
Bug: RsInterface defines compareTo(Object) and uses Object.equals() Pattern id: EQ_COMPARETO_USE_OBJECT_EQUALS, type: Eq, category: BAD_PRACTICE
解釋：
第一段程式碼，沒有使用instanceof判斷就直接轉型，有丟擲classcastexception異常的可能。
這個BUG主題是，遵守約定(x.compareTo(y)==0) == (x.equals(y))，強烈建議，但不嚴格要求。
在return 0的時候，呼叫equals方法返回true，因為在PriorityQueue.remove方法中，1.5使用的是compareTo方法，而1.6使用的是equals方法，保證環境升級的時候，受影響最小。
解決方法：
在return 0的時候，呼叫equals方法返回true
7. NM_METHOD_NAMING_CONVENTION
Bug: The method name MsmPlanDAOTest.TestViewMsmPlanList() doesn’t start with a lower case letter Pattern id: NM_METHOD_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
解釋：
方法應該是動詞，與第一個字母小寫混合的情況下，與每個單詞的首字母大寫的內部。
解決方法：
方法名稱小寫就通過了。
8. HE_EQUALS_USE_HASHCODE
Bug: PerfmSingleGraphPanelRSCategory defines equals and uses Object.hashCode() Pattern id: HE_EQUALS_USE_HASHCODE, type: HE, category: BAD_PRACTICE
解釋：
過載了equals方法，卻沒有過載hashCode方法，如果使用object自己的hashCode，我們可以從JDK原始碼可以看到object的hashCode方法是native的，它的值由虛擬機器分配（某種情況下代表了在虛擬機器中的地址或者唯一標識），每個物件都不一樣。所以這很可能違反“Equals相等，hashcode一定相等；hashcode相等，equals不一定相等。”除非你保證不運用到HashMap/HashTable等運用散列表查詢值的資料結構中。否則，發生任何事情都是有可能的。
關於何時改寫hashcode，請參考：在重寫了物件的equals方法後，還需要重寫hashCode方法嗎?
關於編寫高質量的equals方法：
1.先使用==操作符檢查是否是同一個物件，==都相等，那麼邏輯相等肯定成立；
2.然後使用instanceof操作符檢查“引數是否為正確的型別”；
3.把引數轉換成正確的型別；
4.對於該類中的非基本型別變數，遞迴呼叫equals方法；
5.變數的比較順序可能會影響到equals方法的效能，應該最先比較最有可能不一致的變數，或者是開銷最低的變數。
當你編寫完成equals方法之後，應該問自己三個問題：它是否是對稱的、傳遞的、一致的？
解決方法：
除非你保證不運用到HashMap/HashTable等運用散列表查詢值的資料結構中，請重寫hashcode方法。
9. NM_CONFUSING
Bug: Confusing to have methods xxx.SellerBrandServiceImpl.getAllGrantSellerBrandsByBrandId(long) and xxx.DefaultSellerBrandManager.getALLGrantSellerBrandsByBrandId(long) Pattern id: NM_CONFUSING, type: Nm, category: BAD_PRACTICE
The referenced methods have names that differ only by capitalization.
解釋：
同一個包兩個類中有一模一樣的兩個方法（包括引數）
解決方法：
最好可以修改為不一樣的方法名稱
10. MF_CLASS_MASKS_FIELD
Bug: Field PDHSubCardInstanceDialogCommand.m_instance masks field in superclass ViewNEProperity Pattern id: MF_CLASS_MASKS_FIELD, type: MF, category: CORRECTNESS
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
解釋：
這是什麼意思呢？想要欄位也能夠具有多型性嗎？太迷惑了。
當你想要更新一個m_instance時，你要更新哪個？你用到它時，你知道哪個又被更新了？
解決方法：
要麼去掉其中一個欄位，要麼重新命名。
11. NM_CLASS_NAMING_CONVENTION
Bug: The class name crossConnectIndexCollecter doesn’t start with an upper case letter
解釋： Pattern id: NM_CLASS_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
看到這樣的命名方式，我第一個反映就是有點暈車！
解決方法：
類名第一個字元請大寫。
12. RE_POSSIBLE_UNINTENDED_PATTERN
Bug: “.” used for regular expression Pattern id: RE_POSSIBLE_UNINTENDED_PATTERN, type: RE, category: CORRECTNESS
解釋：
String的split方法傳遞的引數是正則表示式，正則表示式本身用到的字元需要轉義，如：句點符號“.”，美元符號“
”，乘方符號“”，大括號“”，方括號“[]”，圓括號“()”，豎線“|”，星號“∗”，加號“+”，問號“?”等等，這些需要在前面加上“”轉義符。解決方法：在前面加上“”轉義符。13.IAAMBIGUOUSINVOCATIONOFINHERITEDOROUTERMETHOD外部類：內部類：……Bug:AmbiguousinvocationofeitheranouterorinheritedmethodJExtendDialog.onOK()Patternid:IAAMBIGUOUSINVOCATIONOFINHERITEDOROUTERMETHOD,type:IA,cat
1. EC_UNRELATED_TYPES
Bug: Call to equals() comparing different types Pattern id: EC_UNRELATED_TYPES, type: EC, category: CORRECTNESS
解釋：
兩個不同型別的物件呼叫equals方法，如果equals方法沒有被重寫，那麼呼叫object的==，永遠不會相等；如果equals方法被重寫，而且含有instanceof邏輯，那麼還是不會相等。
解決方法：
應該改為str.toString()
2. IM_BAD_CHECK_FOR_ODD
Bug: Check for oddness that won’t work for negative numbers Pattern id: IM_BAD_CHECK_FOR_ODD, type: IM, category: STYLE
解釋：
如果row是負奇數，那麼row % 2 == -1，
解決方法：
考慮使用x & 1 == 1或者x % 2 != 0
3. NP_ALWAYS_NULL
Pattern: Null pointer dereference id: NP_ALWAYS_NULL, type: NP, category: CORRECTNESS
A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed.
4. RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE
Bug: Redundant nullcheck of bean1, which is known to be non-null Pattern id: RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE, type: RCN, category: STYLE
This method contains a redundant check of a known non-null value against the constant null.
這種方法包含了一個稱為非空對空值的不斷重複檢查。
修改為：
5. SS_SHOULD_BE_STATIC
Bug: Unread field: ADDRESS_KEY; should this field be static? Pattern id: SS_SHOULD_BE_STATIC, type: SS, category: PERFORMANCE
This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.
解釋：
final成員變量表示常量，只能被賦值一次，賦值後值不再改變。
這個類包含的一個final變數初始化為編譯時靜態值。考慮變成靜態常量
解決方法：
增加static關鍵字
6. EQ_COMPARETO_USE_OBJECT_EQUALS
Bug: RsInterface defines compareTo(Object) and uses Object.equals() Pattern id: EQ_COMPARETO_USE_OBJECT_EQUALS, type: Eq, category: BAD_PRACTICE
解釋：
第一段程式碼，沒有使用instanceof判斷就直接轉型，有丟擲classcastexception異常的可能。
這個BUG主題是，遵守約定(x.compareTo(y)==0) == (x.equals(y))，強烈建議，但不嚴格要求。
在return 0的時候，呼叫equals方法返回true，因為在PriorityQueue.remove方法中，1.5使用的是compareTo方法，而1.6使用的是equals方法，保證環境升級的時候，受影響最小。
解決方法：
在return 0的時候，呼叫equals方法返回true
7. NM_METHOD_NAMING_CONVENTION
Bug: The method name MsmPlanDAOTest.TestViewMsmPlanList() doesn’t start with a lower case letter Pattern id: NM_METHOD_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
解釋：
方法應該是動詞，與第一個字母小寫混合的情況下，與每個單詞的首字母大寫的內部。
解決方法：
方法名稱小寫就通過了。
8. HE_EQUALS_USE_HASHCODE
Bug: PerfmSingleGraphPanelRSCategory defines equals and uses Object.hashCode() Pattern id: HE_EQUALS_USE_HASHCODE, type: HE, category: BAD_PRACTICE
解釋：
過載了equals方法，卻沒有過載hashCode方法，如果使用object自己的hashCode，我們可以從JDK原始碼可以看到object的hashCode方法是native的，它的值由虛擬機器分配（某種情況下代表了在虛擬機器中的地址或者唯一標識），每個物件都不一樣。所以這很可能違反“Equals相等，hashcode一定相等；hashcode相等，equals不一定相等。”除非你保證不運用到HashMap/HashTable等運用散列表查詢值的資料結構中。否則，發生任何事情都是有可能的。
關於何時改寫hashcode，請參考：在重寫了物件的equals方法後，還需要重寫hashCode方法嗎?
關於編寫高質量的equals方法：
1.先使用==操作符檢查是否是同一個物件，==都相等，那麼邏輯相等肯定成立；
2.然後使用instanceof操作符檢查“引數是否為正確的型別”；
3.把引數轉換成正確的型別；
4.對於該類中的非基本型別變數，遞迴呼叫equals方法；
5.變數的比較順序可能會影響到equals方法的效能，應該最先比較最有可能不一致的變數，或者是開銷最低的變數。
當你編寫完成equals方法之後，應該問自己三個問題：它是否是對稱的、傳遞的、一致的？
解決方法：
除非你保證不運用到HashMap/HashTable等運用散列表查詢值的資料結構中，請重寫hashcode方法。
9. NM_CONFUSING
Bug: Confusing to have methods xxx.SellerBrandServiceImpl.getAllGrantSellerBrandsByBrandId(long) and xxx.DefaultSellerBrandManager.getALLGrantSellerBrandsByBrandId(long) Pattern id: NM_CONFUSING, type: Nm, category: BAD_PRACTICE
The referenced methods have names that differ only by capitalization.
解釋：
同一個包兩個類中有一模一樣的兩個方法（包括引數）
解決方法：
最好可以修改為不一樣的方法名稱
10. MF_CLASS_MASKS_FIELD
Bug: Field PDHSubCardInstanceDialogCommand.m_instance masks field in superclass ViewNEProperity Pattern id: MF_CLASS_MASKS_FIELD, type: MF, category: CORRECTNESS
This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.
解釋：
這是什麼意思呢？想要欄位也能夠具有多型性嗎？太迷惑了。
當你想要更新一個m_instance時，你要更新哪個？你用到它時，你知道哪個又被更新了？
解決方法：
要麼去掉其中一個欄位，要麼重新命名。
11. NM_CLASS_NAMING_CONVENTION
Bug: The class name crossConnectIndexCollecter doesn’t start with an upper case letter
解釋： Pattern id: NM_CLASS_NAMING_CONVENTION, type: Nm, category: BAD_PRACTICE
看到這樣的命名方式，我第一個反映就是有點暈車！
解決方法：
類名第一個字元請大寫。
12. RE_POSSIBLE_UNINTENDED_PATTERN
Bug: “.” used for regular expression Pattern id: RE_POSSIBLE_UNINTENDED_PATTERN, type: RE, category: CORRECTNESS
解釋：
String的split方法傳遞的引數是正則表示式，正則表示式本身用到的字元需要轉義，如：句點符號“.”，美元符號“