一、概要部分
a) 代码符合需求和规格说明书吗?
b) 代码设计是否考虑周全?
c) 代码可读性如何?
d) 代码容易维护吗?
e) 每一行代码都执行并检查过了吗?
二、设计规范部分
a) 设计是否遵从已知的模式或项目中常用的模式?
b) 有没有硬编码或字符串/数字等存在?(使用与配置相分离,只需改配置文件而不需改代码)
c) 代码有没有依赖于某一平台,是否影响将来的移植?(浏览器兼容性)
d) 新写的代码是否出现已有相似功能可以调用却没有调用的情况?(重复编码)
e) 有没有无用代码可以清除?(利用代码控制工具保存原来的老代码)
三、代码规范部分
a) 缩进
四个空格
b) 行宽
100个字符
c) 括号
复杂的条件表达式中应该用括号清楚地表示优先级
d) 大括号
if(true){
Some();
}else{
Some();
}
e) 分行
多个变量多行定义
f) 命名
字符串sVar
数字型iVar
布尔型bVar
数组aVar
对象oVar
g) 下划线
在私有变量或者局部变量中使用。示例:_iVar
h) 大小写
类、变量 名词 Member
函数 动词/动宾组合 getMember
i) 注释
1.不要解释程序是怎么工作的(How)
2.应该解释程序做什么(What)和为什么这样做(Why)
3.需要特别注意的地方
4.不要用中文及特殊字符
5.双斜线后要加一个空格后在写内容
6.意义复杂变量需注明是表示什么的变量
7.方法需注明
@todo: 需要做的事情
@author: 作者(必填)
@review: 记录复审时发现的问题
@bug: 记录已经出现的问题
@param: 对入参的说明(必填)
@return: 对出参的说明(必填)
@exception: 抛出异常的类型
@deprecated: 不建议使用该方法
示例:
/**
* 函数功能简述
*
* 具体描述一些细节
*
* @param {string} address 地址
* @param {array} com 商品数组
* @param {string} pay_status 支付方式
* @returns void
*
* @date 20170707
* @author xxx<xxx@xx.com>
*/
8.简单明了,含义准确
9.注释形式统一
10.注释与代码同步更新
11.发布前删除无用注释
j) 函数
1.只做一件事,并且要做好
2.验证参数正确性
3.断言,方法可能失败的时候要写相应的空判断,再执行接下来的代码
四、具体代码部分
a) 有没有对错误进行处理?
b) 参数传递有无错误?
c) 边界条件是如何处理的?循环有没有可能出现死循环?
d) 有没有使用断言来保证我们认为不变的条件真的得到满足?
e) 数据结构中有没有用不到的元素?
五、效能
a) 代码到效能如何?最坏的情况是怎样的?
b) 代码尤其是循环中是否有明显可优化的部分?
c) 对系统和网络的调用是否会超时,如何处理?
六、可读性
a) 代码的可读性如何?
b) 有没有足够的注释?
七、可测试性
a) 是否需要或创建新的单元测试?