JBuilder 2005代碼審查功能體驗（1）

2019-11-18 12:02:22

字體：大中小

來源：轉載

供稿：網友

　　代碼審查作為JBuilder 2005強大的新特性閃亮登場，直指編碼中的軟肋，力爭將編碼中的錯誤或隱患扼殺于萌芽態，強力提升開發人員的編碼質量。
　　
　　JBuilder 2005根據Sun的編碼規范及軟件開發界總結出的一套行之有效的編碼習慣，對java開發中的編碼風格、聲明風格、Javadoc文檔注釋、EJB規范、命名風格、潛在錯誤、編碼中的畫蛇添足等諸多方面進行代碼審查并給出警示，以便開發人員發現這些不足和隱患予以及時更正。
　　
　　代碼審查和語法錯誤檢查是兩個不同層次的概念。語法錯誤是低層次、強制性的檢查，任何違反語法的程序都是無法通過編譯的，也就是說可運行的程序必須是語法正確的。而代碼審查是高級別，非強制性的檢查，它對語法正確的程序施加了更高更嚴格的要求，從而提升程序的可讀性、降低因變量命名、方法定義、程序邏輯的不完整性等問題而導致程序的潛在出錯機率，增加程序的可維護性和健壯性。
　　
　　林林總總的Java編程規范、編程范式以及編程經驗都致力于提升代碼質量，程序性能，軟件維護性等非語法方法的課題，JBuilder 2005代碼審查即是將各種行之有效的編程規范、范式、經驗施加于你的程序中，以使你的程序遵守這些業已被大量的實踐證實是成功的編程準則。
　　
　　JBuilder 2005在默認的情況下設置的代碼審查機制即是Sun的代碼編程規范，此外還提供了大量可供選擇的審查規則，你可以根據需要激活或關閉這些審查的規則。
　　
　　對于初學者來說，代碼審查無疑是學習和工作的良師益友，JBulder 2005通過即時的代碼審查達到了對開發人員"監督匡正、篤行扶弱"的作用。開發人員也可以通過代碼審查所反饋的問題，學習有關語法之外更多的編程要求和經驗。
　　
　　一、使用代碼審查
　　在默認情況下，JBuilde 2005未激活代碼審查的功能，可以通過Project->Project Properties...->Code Audits調用代碼審查的設置頁。
　　
　　二、代碼風格審查
　　往往有些程序員熱衷于將Java的語法發揮到極致，以資其對Java語法精通的憑據。但在需要充分協作溝通的軟件項目中，簡潔明了，清楚易懂將會受到推崇，晦澀難懂的語句將會受到奚落。故大部分的軟件公司的規范都對語句的精簡明了提出了要求。JBuilder 2005代碼審查可以在一定程度上幫助公司落實和貫徹這一要求。
　　
　　三、聲明審查
　　成員變量和局部變量的隱藏，經常會使開發人員張冠李戴，犯一些不經意的錯誤，而子類隱藏父類的成員和靜態變量經常是由于沒有注重到父類中已經具有相同的名字而引起的，由此而生產的程序Bug由于其隱身性強，是很難被發現，JBuilder 2005提供幾個對聲明進行審查的工具。
　　
　　四、命名風格
　　良好的命名風格在遵守Java命名語法之上，對命名提出了更高的要求，良好的命名風格必須遵守Java的命名規則
　　
　　五、潛在錯誤審查
　　由于流程控制語句語法的非凡性，編寫程序時需要非凡注重，否則將會埋下禍根，JBuilder從多個方面對這些語句進行審查。
　　
　　六、規避各種畫蛇添足
　　JBuilder 2005代碼審查功能的強大還在于能夠判定多余的import包引入、不必要的強制類型轉換、無用成員、多余的接口修飾符等。
　　
　　七、其他
　　在程序中，由于種種原因存在無效表達式，或者程序永遠不能使用的程序段，對于這些無用的代碼，JBuilder 2005提供的代碼審查功能也能查出來，并提醒程序員。
　　
　　總結
　　JBuilder 2005提供了語法之上的代碼審查功能，使用好代碼審查功能不但可以增強程序代碼的簡潔性、可讀性，還可以盡早發現潛在的編碼錯誤，防患于未然。
　　
　　JBuilder 2005代碼審查功能無疑是一項開創性的工作，將對程序開發產生深遠的影響，也是智能開發工具的一個發展方向。
　　
　　使用Jbuilder 2005代碼審查
　　
　　在默認情況下，JBuilde 2005未激活代碼審查的功能，可以通過Project->Project Properties...->Code Audits調用代碼審查的設置頁，如圖1所示：
　　　 JBuilder 2005代碼審查功能體驗（1）（圖一）

　　圖代碼審查設置
　　
　　勾選Code Audits設置頁中的"Enable Code Audits"激活當前工程的代碼審查功能。Code Audits設置頁的左邊是一棵代碼審查規則項的樹，分為兩級，第一級為審查規則項的歸類，點開第一級的節點，第二級的各節點為具體的一個規則項，可以根據需要勾選可取消這些審查的規則。
　　
　　點擊規則項，在Code Audits設置頁的右邊顯示出了該規則的具體描述信息并提供了實例，方便開發人員學習和理解。
　　
　　在激活代碼審查規則后，JBuilder 2005實時地審查編輯器中當前編寫的程序文件，并在違反審查規則代碼四周的控制槽上標注，違反規則代碼的要害處將以一條粉紅色的下劃波浪線標識出來，此外在結構窗格的Warning文件夾下列出當前程序所有違反審查規則的代碼，如圖2所示：
　　 JBuilder 2005代碼審查功能體驗（1）（圖二）

　　圖結構窗格中代碼審查結果匯總
　　
　　審查結果項描述了代碼中存在的問題的簡要描述，通過這個提示和編譯器控制槽上的標識，點選審查結果項時，編輯器中相應的代碼內容將以下劃虛線形式顯示，通過查看相應的代碼，開發人員將能夠快速發現問題所在。更正問題后，對應的審查警告將自動從Warning文件夾中清除。
　　
　　代碼風格審查
　　
　　1、"switch"必須帶一個default語句
　　
　　根據Sun的編碼規范，每個switch流程控制語句都必須帶一個default分支，以保證邏輯分支的完整性。在默認情況下該審查項未激活，對應的設置項是"Coding Style" 下的"'switch' Statement Should Include a Default Case"。
　　
　　代碼清單 1 所有switch必須帶default分支
　　
　　1. switch (formatType)
　　2. {
　　3. 　case 1:
　　4. 　　formatStr = "yyyyMMddHHmmss";
　　5. 　　break;
　　6. 　case 2:
　　7. 　　formatStr = "yyyy'-'MM'-'dd HH:mm:ss";
　　8. 　　break;
　　9. 　case 3:
　　10.　　formatStr = "yyyy.MM.dd HH:mm:ss";
　　11.　　break;
　　12.　case 4:
　　13.　　formatStr = "yyyy'年'MM'月'dd HH:mm:ss";
　　14.　　break;
　　15.　default:
　　16.　　formatStr = "yyyy'-'MM'-'dd HH:mm:ss";
　　17. }
　　
　　假如沒有第15~16行的default代碼，代碼審查將給出警告。
　　
　　提示：
　　
　　可以通過Ctrl+J 調用switch代碼模板錄入的switch流程控制語句代碼塊將帶一個default分支，這樣，不但加速了編碼的錄入效率還保證了代碼塊的規范性。
　　
　　2、應通過類名引用靜態成員
　　
　　類中所有的靜態方法或變量都應該通過類名來引用，假如通過類的實例來引用這些靜態的成員將影響到程序的可讀性。假如通過類名來引用靜態變量，將輕易分辨出這些成員的靜態屬性。因為類靜態成員變量在JVM中僅存在一份，而非每個對象實例各自一份，因此靜態成員變量可以看成類的成員。
　　
　　代碼清單 2 關于靜態成員的引用
　　
　　1. public class ASMO1
　　2. {
　　3. 　void func()
　　4. 　{
　　5. 　　ASMO1 obj1 = new ASMO1();
　　6. 　　ASMO2 obj2 = new ASMO2();
　　7. 　　obj1.attr = 10; //應更正為ASMO1.attr
　　8. 　　obj2.attr = 20; //應更正為ASMO2.attr
　　9. 　　obj1.oper(); //應更正為ASMO1. oper();
　　10. 　 obj2.oper(); //應更正為ASMO2. oper();
　　11.　　this.attr++; //應更正為ASMO2. attr++;
　　12.　　this.oper(); //應更正為ASMO2 oper();
　　13.　}
　　14.
　　15.　static int attr;
　　16.　static void oper()
　　17.　{}
　　18. }
　　19.
　　20. class ASMO2
　　21. {
　　22.　 static int attr;
　　23.　 static void oper()
　　24.　 {}
　　25. }
　　
　　該審查規則對應的設置項是"Coding Style" 下的"accessing Static Members by the Descendant Class Name"。
　　
　　3、避免復雜晦澀代碼
　　
　　往往有些程序員熱衷于將Java的語法發揮到極致，以資其對Java語法精通的憑據。假如是為了練習語法、理解語法，無可厚非。但假如在需要充分協作溝通的軟件項目中，簡潔明了，清楚易懂將會受到推崇，晦澀難懂的語句將會受到奚落。
　　
　　故此，大部分的軟件公司的規范都對語句的精簡明了提出了要求。JBuilder 2005代碼審查可以在一定程度上幫助公司落實和貫徹這一要求。
　　
　　代碼清單3演示了晦澀的賦值語句及替代的寫法：
　　
　　代碼清單 3 復雜晦澀的賦值語句
　　
　　1. int i = 0;
　　2. int j = 0;
　　3. int k = 0;
　　4. int l = 0;
　　5. i *= ++j;
　　6. //應更改為：
　　7. //++j;
　　8. //i *= j;
　　9.
　　10. k = j = 10;
　　11. //應更改為：
　　12. //k = 10;
　　13. //j = 10;
　　14.
　　15. l = j += 15;
　　16. //應更改為：
　　17. //j += 15;
　　18. //l = j;
　　19.
　　20. i = j++ +20;
　　21. //應更改為：
　　22. //i = j + 20;
　　23. //j++;
　　24.
　　25. i = (j = 25) + 30;
　　26. //應更改為：
　　27. //j = 25;
　　28. //i = j + 30;
　　29.
　　30. i = j++ + 20;
　　31. //應更改為：
　　32. //i = j + 20;
　　33. //j++;
　　34.
　　35. i = (j = 25) + 30;
　　36. //應更改為：
　　37. //j = 2

上一篇：JBuilder 2005代碼審查功能體驗（2）

下一篇：在.Net程序中使用log4net記錄日志