代码规范
注释
- 不恰当的信息
/**
* @param num3 待加的数字
*/
public int add(int num1,int num2) {
return num1+num2;
}
就比如上面的代码，注释的参数都不对，有可能是在写作过程中进行了修改，然后没及时的进行添加参数，不正确的参数注释，比不写注释都更容易误导，所以应该避免写注释，尽量让人看到方法名便能明白方法的作用。
- 废弃的注释
/**
* @param num1 待加的数字
* @param num2 待加的数字
* @param num3 待加的数字
*/
public int add(int num1,int num2) {
return num1+num2;
}
可能原来方法中存在三个参数，但是后来方法发生了变更，只剩下两个参数了，但是注释中的参数却没有及时消掉。
- 冗余注释
/**
* @param num1 待加的数字
* @param num2 待加的数字
*/
public int add(int num1,int num2) {
return num1+num2;//返回两个数相加后的结果
}
上面的代码中就是注释的严重冗余，明明很简单的，一眼就能看得懂的，非要加一些注释来干扰阅读。
- 糟糕的注释
/**
* 该方法用于实现两个数的相加，一个数用来作为第一个参数，另一个作为第二个参数，并在最后把他们的相加的结果返回
* @param num1 待加的数字
* @param num2 待加的数字
*/
public int add(int num1,int num2) {
return num1+num2;//返回两个数相加后的结果
}
看注释了半天，也不知道这个是干嘛的。
- 注释掉的代码
/**
* 该方法用于实现两个数的相加，一个数用来作为第一个参数，另一个作为第二个参数，并在最后把他们的相加的结果返回
* @param num1 待加的数字
* @param num2 待加的数字
*/
/*public int add(int num1,int num2) {
return num1+num2;//返回两个数相加后的结果
}*/
把代码注释掉而不删除，不能看做是一个程序员应该做的，在现在的代码中，大部分都用到了代码版本管理工具，完全不需要担心，注释了代码之后，就没法再把代码进行还原回来。不用的代码就及时的干掉，不要放在这里干扰阅读
环境
- 需要多步才能实现的构建
- 需要多步才能做到的测试
函数
- 过多的参数
- 输出参数
- 标识参数
- 死函数
一般性问题
- 一个源文件中存在多种语言
- 明显的行为未被实现
- 不正确的边界行为
- 忽视安全
- 重复
- 在错误的抽象层级上的代码
- 基类依赖于派生类
- 信息过多
- 死代码
- 垂直分割
- 前后不一致
- 混淆视听
- 人为耦合
- 特性依恋
- 选择布尔参数
- 晦涩的意图
- 位置错误的权责
- 使用解释性变量-》将计算过程打散
- 函数名称应该表达其行为
- 理解算法
- 把逻辑依赖改为物理依赖
- 使用多态代替If/Else或Switch/Case
- 遵循标准约定
- 使用命名常量代替魔法数
- 准确
- 结构甚于约定
- 封装方法
- 避免否定性条件
- 函数只做一件事
- 掩蔽时序耦合-》顺序调用产生下一个函数所需的结果
- 封装边界条件
- 函数只在一个抽象层级上
- 在较高层级放置可配置数据
- 避免传递浏览
Java
- 避免使用通配符过长导入类
- 不要继承常量
- 使用枚举代替常量
名称
- 采用描述性名称
- 名称应和抽象层级相符
- 尽可能使用标准命名法
- 无歧义的名称
- 为较大作用范围选用较长名称
- 避免编码-》前缀
- 名称说明具体作用
测试
- 测试不足
- 使用覆盖率工具
- 别略过小测试
- 被忽略的测试就是对不确定事物的疑问
- 测试边界条件
- 全面测试相近的缺陷
- 测试失败的模式有启发性
- 测试覆盖率的模式有启发性
- 测试应该快速