我的code review规则


1) 是否有语法错误,编译错误,编译警告。
做法:下载最新代码,将编译警告级别提升到最高,检查output信息。

2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少。
注意:即使发现有问题代码,如果与需求关联不大,不要涉及。
应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少。

3)是否符合编码规范:
	a) 注意等号前后,操作符前后的空格和tab,行尾不要有多余空白字符
	b) 注意命名规范,少用缩写形式,少用2/3/ex这种增强版
	c) 对于循环局部变量,注意少用I,j在较长代码中(三四行OK)
	d) ..

4)代码美感
	a) 不能有嵌套的if-for-switch-while出现
	b) 不能有非常复杂的条件判断表达式(用于if-while之类)
	c) 足够的注释,对于复杂操作,对于条件判断,可以注释。尽量让代码自己说明自己。
 	d) 如果代码不能在短时间内理解,或者稍作解释就可以理解,应该看看能否有更简洁的方式
	e) 函数不要过长,不能超过一屏显示,最多不应该超过2-3屏。
	f)经常问自己是否有更好的办法,更简洁明了的代码形势
	g) 一个函数只做一件事,如果需要多个功能,再写一个
	h) 少用boolean 作为参数切换功能,用withXXXcase, usingXXXcondition函数名字来自说明。道理同g)
	i) 少用重载功能,没必要类似函数用一个名字,既然有不同函数实现,那么应该有不同条件描述,可参考h)的命名
	j) 抽象层次不要过多,不要过早和过多考虑设计模式/抽象/抽取通用功能这些事情,这些在代码重构阶段可以修改调整。

5)逻辑
	a) 参考上一条4),基本上有足够美感的代码,逻辑上问题都不大

6)杂项
	a) 性能的关注应该基于profiling data,而不是猜测
	b) 代码的正确与否,不是基于猜测而是基于test case
	c) 扩展性不需要考虑过多,有一点点就好
	d) 时时问自己,这个函数/变量/逻辑判断/.. 有没有必要,是不是可以删掉的
	e) 时时问自己,如果不用手动测试,自动化测试自己这段代码,可以不可以?如何实现?(MEF or 数据界面分离… )可否通过脚本、工具自动化某些流程?

《“我的code review规则”》 有 1 条评论

  1. 嗯~很全。
    不过,第一条不是规则。不能break build,不能有编译警告是code review的入门条件。杂项里关于自动测试不是必须的吧?

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注