为什么需要编码规范?
- 提高效率
- 提高质量
- 降低维护成本
- 让别人也遵守 形成良性的环境
编码规范的检查清单
代码是按照编码指南编写的吗?
代码能够按照预期工作吗?
文件是不是在合适的位置?
支撑文档是不是充分? 代
码是不是易于阅读、易于理解?代
码是不是易于测试和调试?
有没有充分的测试, 覆盖关键的逻辑和负面清单?
名字是否遵守命名规范? 名字是不是拼写正确、 简单易懂?
名字是不是有准确的意义?
代码的分块是否恰当?
代码的缩进是否清晰、 整洁?
有没有代码超出了每行字数的限制?
代码的换行有没有引起混淆?
每一行代码是不是只有一个行为?
变量的声明是不是容易检索和识别?
变量的初始化有没有遗漏?
括号的使用是不是一致、 清晰?
源代码的组织结构是不是一致? 版权信息的日期有没有变更成最近修改日期?
限定词的使用是不是遵循既定的顺序?
有没有注释掉的代码?
有没有执行不到的代码?
有没有可以复用的冗余代码?
复杂的表达式能不能拆解成简单的代码块?
代码有没有充分的注释?
注释是不是准确、 必要、 清晰?
不同类型的注释内容,
注释的风格是不是统一?
有没有使用废弃的接口?
能不能替换掉废弃的接口?
不再推荐使用的接口, 是否可以今早废弃?
继承的方法,有没有使用Override注解?
有没有使用异常机制处理正常的业务逻辑?
异常类的使用是不是准确?
异常的描述是不是清晰?
是不是需要转换异常的场景?
转换异常场景, 是不是需要保留原异常信息?
有没有不应该被吞噬的异常?
外部接口和内部实现有没有区分隔离?
接口规范描述是不是准确、 清晰?
接口规范有没有描述返回值?
接口规范有没有描述运行时异常?
接口规范有没有描述检查型异常?
接口规范有没有描述指定参数范围?
接口规范有没有描述边界条件?
接口规范有没有描述极端状况?
接口规范的起草或者变更有没有通过审阅?
接口规范需不需要标明起始版本号?
产品设计是不是方便用户使用?
用户指南能不能快速上手?
用户指南的示例是不是可操作?
用户指南和软件代码是不是保持一致?