前端代码质量检查

代码质量的保证事关团队作战的战斗力。军歌里不是这么唱的吗：“我们都是神枪手，每一颗子弹消灭一个敌人！”我们都是攻城师，每一行代码消灭一个需求！

如何让一个团队的人产出的代码都在一个基本水平底线之上呢？最初是靠制订规范。要确保规范得以执行只能靠人，所以文字规范成了code review的公共参照标准。单纯靠人的事最终都容易流于形式，所以需要工具加以保证。

几乎所有成熟的语言都有Lint工具，对代码进行静态分析找出问题。于是老道(Douglas Crockford)很有远见的在2002年就开发了JSLint(http://www.jslint.com/)弥补了Javascript这方面的空白。但现在仍有很多人敬而远之，理由是过于严格。

其实问题出在使用方式上。如果能把这个工具跟自己正在用的代码规范结合起来，忽略那些过于“苛刻”的规则是最理想的。去年，我们公开了我们的Javascript代码规范（http://bit.ly/douban-javascript 翻墙）。制订一个实用的代码规范需要注意：

1. 参照性强。不要冗长要精练。在code review时很容易成为check list使用。
2. 可检验性强。方便跟工具结合，实现自动化检验

这样双管齐下，就可以确保规范得以更好的贯彻执行。

今天要介绍的Douban-JSLint，就是为规范定制的工具。它是nodeJS版的，对比用Java+Rhino的使用方式，方便多了，也易于安装和升级。安装方法：

第1步，当然要先有nodeJS环境(安装参考：https://github.com/joyent/node/wiki/Installation)
第2步，推荐用npm（nodeJS包管理工具）安装： npm install http://github.com/kejun/Douban-JSLint/tarball/master

或者，也可以先将源码clone下来（如果装了git），进入目录，再用 npm install . 完成安装。

这样就装完了。使用时：

单个检查：
douban-jslint file.js

批量检查：
douban-jslint *.js
douban-jslint file1.js file2.js

有错的情况会是这样：
mine.js (line at 114, character 56): Missing semicolon.
                                self.html(eval('('+r+')').html)
mine.js (line at 115, character 25): 'load_event_monitor' is not defined.
                                load_event_monitor(self);
mine.js (line at 119, character 27): 'mine_page_url' is not defined.
                                $.post_withck(mine_page_url,{
mine.js (line at 126, character 2): Missing semicolon.
        )
... ...
-----------------------------------
28 error(s)

说明：其中的load_event_monitor是一个其它类库的方法，mine_page_url是一个全局变量，这种其实属于正常情况。要避免这种情况，只需要在文件中声明一下即可：
/*global load_event_monitor: true, mine_page_url: true */

如果成功了，会看到这样的结果：
checking "/Users/Kejun/Sites/douban/do/do.js" (8026 characters) …
-----------------------------------
Good! 0 error


JSLint的配置其实还是挺灵活的。Douban-JSLint里做出一些调整，参见源码：
https://github.com/kejun/Douban-JSLint/blob/master/bin/jslint.js

源码中的options对象是标准的配置（详细参考：http://www.jslint.com/lint.html#options）。
 evil - 禁用eval
undef - 必须声明变量,
eqeqeq - 精确判断
fragment - 允许检查html片段
predef - 定义了一些默认的全局变量。

除了这些基本配置外，其实还可以再进一步设置。关掉一些过滤条件，如：

ok = {

        // 允许这种写法： foo && foo(this);
      "Expected an assignment or function call and instead saw an expression.": true,

      // 允许这种写法： for (; el = els[i++]; )
      "Expected a conditional expression and instead saw an assignment.": true,

      // 允许csshack中的常用特殊字符，如"_", "*"
      "Unexpected '-'.": true,
      "Unexpected '_'.": true,
      "Unexpected '*'.": true
}

通过这些调整就可以检查规范中的大部分条款了。其中仍有一些是JSLint查不出来的，如：长语句的断行

最省事的办法是用其它工具弥补。我推荐的是google的Closure Linter。它有一个最强悍的功能－自动修复。在实际使用时一般先修复一下：
$ fixjsstyle file.js

跑一下douban-jslint
$ douban-jslint file.js

再跑一下closure linter
$ gjslint file.js

关于Clousre Linter参见：
http://code.google.com/closure/utilities/docs/linter_howto.html

在我们的代码开发流程里加入对代码的质量检验是很有必要的。同时，使用开源工具时一定要考虑跟实际应用结合，才能发挥出更大的作用。