必備idea 插件plugins 提高編碼效率

本文轉載自查看原文 2019-06-10 12:24 4400

最近發現了幾個非常好用提高編碼效率的idea 插件跟大家分享一下

因為idea自帶的插件下載可能連接不上服務器而導致插件下載失敗，所以這里推薦使用引入外部插件的方式

插件包也給你們准備好了（你們無需去下載啦），對照此篇博客配置即可：

　　鏈接：https://pan.baidu.com/s/1VKXJ74W3s6RZHL-3YHlaEA 密碼：z411

首先說一下idea引入外部插件的方式：

1.打開settings配置面板

2.選擇plugins--》install pluginfrom disk 選擇相應插件包==》點擊ok

最后，“Restart”重啟idea 讓它加載一下新加入的插件！！！

常用插件：

下面的所有插件都使用上面外部引用方式集成相應的插件包即可

1. FindBugs-IDEA

作用：

檢測代碼中可能的bug及不規范的位置，

寫完代碼后檢測下避免低級bug，

靜態分析工具承諾無需開發人員費勁就能找出代碼中已有的缺陷。當然，如果有多年的編寫經驗，就會知道這些承諾並不是一定能兌現。

插件提供地址：

https://plugins.jetbrains.com/plugin/3847-findbugs-idea

成功標志：

重啟idea后如果插件加載成功左下角出現：

實際應用：

----------------------

掃描完成后：

附錄（網摘）：

FindBugs 它用來查找Java代碼中存在的bug。它使用靜態分析方法標識出Java程序中上百種潛在的不同類型的錯誤。

FindBugs支持對包級別、項目級別、模塊級別、單個文件級別，以及自定義范圍的Bug分析。

FindBugs：特色是能夠檢查出空指針異常這種bug！

使用：右鍵單擊（module、單個文件等）--->在快捷菜單中選擇findbugs即可

附:FindBugs的Bug種類說明

· Bad practice 壞的實踐

一些不好的實踐，下面列舉幾個：
HE：類定義了equals()，卻沒有hashCode()；或類定義了equals()，卻使用Object.hashCode()；或類定義了hashCode()，卻沒有equals()；或類定義了hashCode()，卻使用Object.equals()；類繼承了equals()，卻使用Object.hashCode()。
SQL：Statement 的execute方法調用了非常量的字符串；或Prepared Statement是由一個非常量的字符串產生。
DE：方法終止或不處理異常，一般情況下，異常應該被處理或報告，或被方法拋出。
Malicious code vulnerability 可能受到的惡意攻擊

如果代碼公開，可能受到惡意攻擊的代碼，下面列舉幾個：
FI：一個類的finalize()應該是protected，而不是public的。
MS：屬性是可變的數組；屬性是可變的Hashtable；屬性應該是package protected的。

類名小寫問題：

· Correctness 一般的正確性問題

可能導致錯誤的代碼，下面列舉幾個：
NP：空指針被引用；在方法的異常路徑里，空指針被引用；方法沒有檢查參數是否null；null值產生並被引用；null值產生並在方法的異常路徑被引用；傳給方法一個聲明為@NonNull的null參數；方法的返回值聲明為@NonNull實際是null。
Nm：類定義了hashcode()方法，但實際上並未覆蓋父類Object的hashCode()；類定義了tostring()方法，但實際上並未覆蓋父類Object的toString()；很明顯的方法和構造器混淆；方法名容易混淆。
SQL：方法嘗試訪問一個Prepared Statement的0索引；方法嘗試訪問一個ResultSet的0索引。
UwF：所有的write都把屬性置成null，這樣所有的讀取都是null，這樣這個屬性是否有必要存在；或屬性從沒有被write。

· Dodgy 危險的

具有潛在危險的代碼，可能運行期產生錯誤，下面列舉幾個：
CI：類聲明為final但聲明了protected的屬性。
DLS：對一個本地變量賦值，但卻沒有讀取該本地變量；本地變量賦值成null，卻沒有讀取該本地變量。
ICAST：整型數字相乘結果轉化為長整型數字，應該將整型先轉化為長整型數字再相乘。
INT：沒必要的整型數字比較，如X <= Integer.MAX_VALUE。
NP：對readline()的直接引用，而沒有判斷是否null；對方法調用的直接引用，而方法可能返回null。
REC：直接捕獲Exception，而實際上可能是RuntimeException。
ST：從實例方法里直接修改類變量，即static屬性。

· Performance 性能問題

可能導致性能不佳的代碼，下面列舉幾個：
DM：方法調用了低效的Boolean的構造器，而應該用Boolean.valueOf(…)；用類似Integer.toString(1) 代替new Integer(1).toString()；方法調用了低效的float的構造器，應該用靜態的valueOf方法。
SIC：如果一個內部類想在更廣泛的地方被引用，它應該聲明為static。
SS：如果一個實例屬性不被讀取，考慮聲明為static。
UrF：如果一個屬性從沒有被read，考慮從類中去掉。
UuF：如果一個屬性從沒有被使用，考慮從類中去掉。

· Multithreaded correctness 多線程的正確性多線程編程時，可能導致錯誤的代碼，下面列舉幾個：

ESync：空的同步塊，很難被正確使用。
MWN：錯誤使用notify()，可能導致IllegalMonitorStateException異常；或錯誤的使用wait()。
No：使用notify()而不是notifyAll()，只是喚醒一個線程而不是所有等待的線程。
SC：構造器調用了Thread.start()，當該類被繼承可能會導致錯誤。

· Internationalization 國際化
當對字符串使用upper或lowercase方法，如果是國際的字符串，可能會不恰當的轉換。