code review (ZZ)

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 数据界面分离… )可否通过脚本、工具自动化某些流程？