JBuilder 2005代码审查功能体验（2）

核心提示：命名风格1、取消不良命名习惯良好的命名风格在遵守java命名语法之上，对命名提出了更高的要求，JBuilder 2005代码审查功能体验（2），良好的命名风格必须遵守以下的命名规则：1) 类或接口必须以大写字母打头，2) 方法、属性、成员变量、局部变量以小写字母打头，而非判定两者是否具有值，应该使用equals()替代

　　命名风格
　　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 变量本身无意义的常见数据类型答应的单字符变量
　　
　　此外，为了减少潜在的冲突，避免不必要的混淆，不答应以大写域名或国家代码作变量名。
　　
　　代码清单 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、将布尔变量和布尔值比较
　　
　　没有必要将布