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

2019-11-18 12:02:22

字體：大中小

來源：轉載

供稿：網友

　　命名風格
　　1、取消不良命名習慣
　　
　　良好的命名風格在遵守java命名語法之上，對命名提出了更高的要求，良好的命名風格必須遵守以下的命名規則：
　　
　　1) 類或接口必須以大寫字母打頭。
　　
　　2) 方法、屬性、成員變量、局部變量以小寫字母打頭，且不以"_"或"$"打頭。
　　
　　3) 常量的所有字母都大寫。
　　
　　4) 異常類以Exception結尾。
　　
　　良好命名對應"Naming Style"下的"Naming Conventions"設置項。
　　
　　2、建立和國際接軌的包名
　　
　　包名應該用頂級域名打頭，如com，org，edu等，或者用國家代碼如cn，ru等。
　　
　　一般公司和組織都對包名前兩級都有嚴格的規則，如IBM公司的類以com.ibm打頭，apache以org.apache打頭，第三級才是具體的項目或產品名稱，這樣的包命名就象三維網的URL命名一樣已經成為了一種國際通用的準則。對此沒有作出嚴格規定的公司，開發負責人應該推動建立起符合這一命名規則的規范。
　　
　　該審查項，默認情況下沒有激活，可以通過"Naming Style"下的"Package Name"的設置項激活。
　　
　　3、避免用過于簡單的變量名
　　
　　除了循環體中的臨時變量，及一些沒有非凡意義的常見數據類型，應該盡量避免使用一個字符作為變量。那些無非凡意義且常見的數據類型，所選取的單字符變量名必須按表1進行命名：
　　
　　表 1 變量本身無意義的常見數據類型答應的單字符變量
　　 JBuilder 2005代碼審查功能體驗（2）

　　此外，為了減少潛在的沖突，避免不必要的混淆，不答應以大寫域名或國家代碼作變量名。
　　
　　代碼清單 10 取有意義的變量名
　　
　　1. void method(double d)
　　2. {
　　3. 　int i;
　　4. 　Exception e;
　　5. 　char s;//應該改為c
　　6. 　Object f;//應該改為o
　　7. 　String k;//應該改為s
　　8. 　Object UK;//和英國國家代碼相同，應改為其他的名字，如ukObj
　　9. 　Object COM;//和域名相同，應改為其他的名字，如obj_1
　　10. }
　　
　　該審查項，在默認情況下沒有激活，可以通過"Naming Style"下的"Use Conventional Variable Names"的設置項激活。
　　
　　潛在錯誤審查
　　1、聚焦switch
　　
　　由于switch流程控制語句語法的非凡性，編寫程序時需要非凡注重，否則將會埋下禍根，JBuilder從以下3個方面對switch進行審查：
　　
　　1) 有無對前面沒有break語句的case從句作標識：根據Sun編碼慣例，程序入口點從一個case進入，直接到達下一個case代碼段，即前一個case沒有對應的break語句時，在跨過的地方必須給出一個顯示的注釋，表示是特定流程控制的要求，而非無意遺漏。來看下面的代碼：
　　
　　代碼清單 11 沒有break的case從句
　　
　　1. switch (c) {
　　2. 　case '+':
　　3. 　　...
　　4. 　　break;
　　5. 　case '-':
　　6. 　　...
　　7. 　case 'n':
　　8. 　　...
　　9. 　case ' ': case '/t':
　　10. 　...
　　11. 　break;
　　12. }
　　
　　假設在代碼清單11的第7行之前，是因為疏忽而遺漏了一個break語句，第9行之前是邏輯需要而故意不加break語句，則將代碼更改為：
　　
　　代碼清單 12 更正的switch代碼
　　
　　1. switch (c) {
　　2. 　case '+':
　　3. 　　...
　　4. 　　break;
　　5.　 case '-':
　　6.　　 ...
　　7. 　　break;
　　8. 　case 'n':
　　9. 　　...
　　10. 　//繼續運行到下面
　　11. 　case ' ': case '/t':
　　12. 　　...
　　13. 　　break;
　　14. }
　　
　　該審查內容對應于"Possible Errors"下的"Break Statement is Missing before Case clause"設置項。
　　
　　2) 在switch中出現非case的標簽：在Java語句中有兩個標簽，即case分支標簽，另一個則是語句標簽，假如case分支標簽語句誤刪或遺漏了case要害字，則case分支標簽將變成語句標簽，而編譯器無法識別這個錯誤。
　　
　　代碼清單 13 case分支中缺少case而使標簽發生質變
　　
　　1. public class CaseLabel
　　2. {
　　3. 　/**點*/
　　4. 　public static final int POINT = 1;
　　5.　 /**線*/
　　6. 　public static final int LINE = 2;
　　7. 　/**多邊形*/
　　8. 　public static final int POLYGON = 3;
　　9.
　　10.　public String getFigureType (int kind)
　　11. 　{
　　12. 　　String tempName = null;
　　13. 　　switch (kind)
　　14. 　　{
　　15. 　　　case POINT:
　　16. 　　　　LINE://該語句缺少case,編譯器將其作為語句標簽處理，并不會發生語法錯誤
　　17. 　　　　//但該方法傳入常量LINE時，將轉到default分支中，而非到達這晨，故
　　18. 　　　　//應該將該行語句更改為case LINE:
　　19. 　　　　tempName = "POINT and LINE";
　　20. 　　　　break;
　　21. 　　　case POLYGON:
　　22. 　　　　tempName = "POLYGON";
　　23. 　　　　break;
　　24. 　　　default:
　　25. 　　　　tempName = "UNDEFINE";
　　26. 　　}
　　27. 　　return tempName;
　　28. 　}
　　29. }
　　
　　該審查內容對應于"Possible Errors"下的"Non-Case Label in Switch statement"設置項。
　　
　　3) 有錯誤嫌疑的break和continue：break和continue用于switch和循環中的跳轉控制，break用于提前結束循環以及從switch中退出，break的這種"多態性"使得在循環體中內嵌switch語句時，常會帶來一些隱患。即開發者本希望退出外層循環，結果卻只退出內層的switch語句而已。JBuilder 2005對這項內容的審查包括以下方面：
　　
　　switch內嵌于循環體中，且case從句中包含了不位于分支塊最后位置的break語句。
　　switch內嵌于循環體中，且case從句既使用了break，又使用了continue，但兩者的效果卻是一樣的。
　　break或continue語句中使用了不必要的語句標簽。
　　
　　請看下面的代碼：
　　
　　代碼清單 14有錯誤嫌疑的break和continue
　　
　　1. void scan(char[] arr)
　　2. {
　　3. 　loop:
　　4. 　for (int i = 0; i < arr.length; i++)
　　5. 　{
　　6. 　　switch (arr[i])
　　7. 　　{
　　8. 　　　case '0':case '1':case '2':case '3':case '4':
　　9. 　　　//5~6的數字
　　10. 　　case '5':case '6':case '7':case '8':case '9':
　　11. 　　{
　　12. 　　　if (PRocessDigit(arr[i]))
　　13. 　　　{
　　14. 　　　　continue loop; //loop語句標簽沒有必要
　　15.　　　 }
　　16. 　　　else
　　17. 　　　{
　　18. 　　　　break; // 該break不會結束for循環,應該使用break loop才可結束循環
　　19. 　　　}
　　20. 　　}
　　21.　　 case ' ':case '/t':
　　22. 　　{
　　23. 　　　processWhitespace(arr[i]);
　　24.　　　 continue; // 應該使用break而非continue
　　25.　　 }
　　26. 　　default:
　　27. 　　　processLetter(arr[i]);
　　28. 　　　break;
　　29. 　}
　　30. }
　　
　　該審查內容對應于"Possible Errors"下的"Suspicious Break/Continue"設置項。
　　
　　2、避免對浮點值進行等值邏輯判定
　　
　　浮點數都是一定精度的數據，由于內部表示的誤差，往往字面上相同的兩個浮點數，其內部表示也不完全相同。故此應避免對浮點值數進行等值邏輯判定，而應采用邏輯比較判定。
　　
　　代碼清單 15 語句中包含浮點等值判定
　　
　　1. void calc(double limit)
　　2. {
　　3.　 if (limit == 0.0)//應改為通過和較小值比較來判定，如if(Math.abs(limit) < 0.0000001)
　　4. 　{
　　5. 　　System.out.println(" the float-point number is exactly 0");
　　6.　 }
　　7. }
　　
　　該審查內容默認未激活可以通過"Possible Errors"下的"Suspicious Break/Continue"設置項來激活審查。
　　
　　3、添加()清楚化復雜的表達式
　　
　　寫復雜的表達式時不應過度依靠運算操作符的計算優先順序，而應養成使用"()"的好習慣，當一個邏輯表達式由多個邏輯運算組成時，應該用"()"劃分不同的部分。
　　
　　代碼清單 16 用括號清楚化表達式
　　
　　1. boolean a, b, c;
　　2. ...
　　3. if (a b && c) //應該替換成if ((a b) && c)
　　4. {
　　5. ...
　　6. }
　　
　　該審查內容默認未激活可以通過"Possible Errors"下的"Mixing Logical Operators Without Parentheses"設置項來激活審查。
　　
　　4、字符串比較
　　
　　Java初學者一個常犯的錯誤是使用"=="或"!="對字符串進行等值邏輯判定。使用"=="將判定兩者否是指向相同的對象引用，而非判定兩者是否具有值，應該使用equals()替代。
　　
　　代碼清單 17 用equals()替換"=="
　　
　　1. public boolean equals(String s1, String s2)
　　2. {
　　3. 　return s1 == s2; //應改為return s1.equals(s2);
　　4. }
　　
　　該審查內容對應于"Possible Errors"下的"Use 'equals' Instead of '= ='"設置項。
　　
　　規避各種畫蛇添足
　　1、將布爾變量和布爾值比較
　　
　　沒有必要將布

上一篇：學習XHTM+CSS2.0制作標準站點方法

下一篇：JBuilder 2005代碼審查功能體驗（1）