代码整洁规范要求

代码规范

注释

• 不恰当的信息

/*** &＃64;param num3 待加的数字*/public int add(int num1,int num2) {return num1&＃43;num2;}


就比如上面的代码&＃xff0c;注释的参数都不对&＃xff0c;有可能是在写作过程中进行了修改&＃xff0c;然后没及时的进行添加参数&＃xff0c;不正确的参数注释&＃xff0c;比不写注释都更容易误导&＃xff0c;所以应该避免写注释&＃xff0c;尽量让人看到方法名便能明白方法的作用。

• 废弃的注释

/*** &＃64;param num1 待加的数字* &＃64;param num2 待加的数字* &＃64;param num3 待加的数字*/public int add(int num1,int num2) {return num1&＃43;num2;}


可能原来方法中存在三个参数&＃xff0c;但是后来方法发生了变更&＃xff0c;只剩下两个参数了&＃xff0c;但是注释中的参数却没有及时消掉。

• 冗余注释

/*** &＃64;param num1 待加的数字* &＃64;param num2 待加的数字*/public int add(int num1,int num2) {return num1&＃43;num2;//返回两个数相加后的结果}


上面的代码中就是注释的严重冗余&＃xff0c;明明很简单的&＃xff0c;一眼就能看得懂的&＃xff0c;非要加一些注释来干扰阅读。

• 糟糕的注释

/*** 该方法用于实现两个数的相加&＃xff0c;一个数用来作为第一个参数&＃xff0c;另一个作为第二个参数&＃xff0c;并在最后把他们的相加的结果返回* &＃64;param num1 待加的数字* &＃64;param num2 待加的数字*/public int add(int num1,int num2) {return num1&＃43;num2;//返回两个数相加后的结果}


看注释了半天&＃xff0c;也不知道这个是干嘛的。

• 注释掉的代码

/*** 该方法用于实现两个数的相加&＃xff0c;一个数用来作为第一个参数&＃xff0c;另一个作为第二个参数&＃xff0c;并在最后把他们的相加的结果返回* &＃64;param num1 待加的数字* &＃64;param num2 待加的数字*//*public int add(int num1,int num2) {return num1&＃43;num2;//返回两个数相加后的结果}*/


把代码注释掉而不删除&＃xff0c;不能看做是一个程序员应该做的&＃xff0c;在现在的代码中&＃xff0c;大部分都用到了代码版本管理工具&＃xff0c;完全不需要担心&＃xff0c;注释了代码之后&＃xff0c;就没法再把代码进行还原回来。不用的代码就及时的干掉&＃xff0c;不要放在这里干扰阅读

环境

• 需要多步才能实现的构建
• 需要多步才能做到的测试

函数

• 过多的参数
• 输出参数
• 标识参数
• 死函数

一般性问题

• 一个源文件中存在多种语言
• 明显的行为未被实现
• 不正确的边界行为
• 忽视安全
• 重复
• 在错误的抽象层级上的代码
• 基类依赖于派生类
• 信息过多
• 死代码
• 垂直分割
• 前后不一致
• 混淆视听
• 人为耦合
• 特性依恋
• 选择布尔参数
• 晦涩的意图
• 位置错误的权责
• 使用解释性变量-》将计算过程打散
• 函数名称应该表达其行为
• 理解算法
• 把逻辑依赖改为物理依赖
• 使用多态代替If/Else或Switch/Case
• 遵循标准约定
• 使用命名常量代替魔法数
• 准确
• 结构甚于约定
• 封装方法
• 避免否定性条件
• 函数只做一件事
• 掩蔽时序耦合-》顺序调用产生下一个函数所需的结果
• 封装边界条件
• 函数只在一个抽象层级上
• 在较高层级放置可配置数据
• 避免传递浏览

Java

• 避免使用通配符过长导入类
• 不要继承常量
• 使用枚举代替常量

名称

• 采用描述性名称
• 名称应和抽象层级相符
• 尽可能使用标准命名法
• 无歧义的名称
• 为较大作用范围选用较长名称
• 避免编码-》前缀
• 名称说明具体作用

测试

• 测试不足
• 使用覆盖率工具
• 别略过小测试
• 被忽略的测试就是对不确定事物的疑问
• 测试边界条件
• 全面测试相近的缺陷
• 测试失败的模式有启发性
• 测试覆盖率的模式有启发性
• 测试应该快速