编写规范代码的检查清单

为什么需要编码规范？

1. 提高效率
2. 提高质量
3. 降低维护成本
4. 让别人也遵守 形成良性的环境

编码规范的检查清单

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