http://sunxiunan.com/?p=1929
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 数据界面分离… )可否通过脚本、工具自动化某些流程？