首页 > 学院 > 开发设计 > 正文

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、将布尔变量和布尔值比较
  
  没有必要将布

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表