JSHint: 规范团队的JavaScript代码
历史
2008年，Douglas Crockford大神写完《JavaScript:The Good Parts》 http://book.douban.com/subject/11874748/ 之后，给JavaScript树立了一个完整的技术规范,算是给JavaScript正名了（设计还是可以的，关键是要用好）。然后他老人家心想说：“老子告诉你们什么是好的JavaScript了，再送你们一个检测工具吧，凡是过不了我规范就不是好的JavaScript代码，Warning: JSLint will hurt your feelings”。当然除了最后Warning那句，其它都是我YY的。总之，就是老头根据自己的理念用JavaScript写了一个JavaScript代码规范检查工具，这就是JSLint（http://www.jslint.com/），后来非常流行，也的确帮助了广大的JavaScript程序员。但是因为这老头的个性既霸道又固执（很多大神貌似都这样子...），对于自己的代码规范不做丝毫的妥协，对开源社区的反馈的回应也很不礼貌。（ https://raw.githubusercontent.com/disqus/disqus.github.com/master/_posts/2011-02-20-antonkovalyov-why-i-forked-jslint-to-jshint.html） 于是，JSLint从一个帮助程序员规范代码，避免Bug的工具，变成了一个让你写的代码像Crockford的工具。在最不信神的IT界，这当然不能忍了。 2011年，一个叫Anton Kovalyov的前端程序员借助开源社区的力量弄出来了JSHint，其思想基本上和JSLint是一致的，但是其有一下几项优势：
安装，使用
还是情不自禁的啰嗦一下，在我看来，Node最大的功绩不在于让JavaScript可以写后台程序，而在于其繁荣了整个前端开源社区。在Node环境下，安装JSHint非常简单：
然后就可以通过如下的命令检测代码
默认情况下会得到如下的结果
./app/model.js: line 27, col 2, Missing semicolon.
配置与规则
前面已经提到，JSHint最大的优势在于其可配置性。JSHint的确提供了非常细致的配置规则。
开发者可以通过3种方式指定团队的代码规范：
运行时通过--config指定配置文件。
使用特殊的文件名.jshintrc, 运行时jshint会从当前路径下开始，一层一层往上找。
自己把规则配置到项目的package.json中，放置到属性名jshintConfig下。
JSHint的config文件就是一个json文件，里面配置的就是一堆的JSHint规则， 如下：
例子中的配置规则要求：
JSHint配置文件中的规则有3类：
JSHint支持的所有规则,以及每个规则的值应该怎么填。参见： http://www.jshint.com/docs/options/。
前面提到了可以通过配置文件指定项目中的JavaScript代码需要遵守的规则，但是在实际项目中，存在某个文件需要特别的处理，或者是某个文件的某个方法需要特别的宽容的情况，对于这种情况，JSHint提供了一些指令内嵌到JavaScript代码中，在JSHint检查的时候会根据指令进行处理。JSHint提供的指令有：
jshint:设置JSHint规则，eg：/ jshint strict: true /
jslint: 设置JSHint兼容的JSLint规则，eg: / jslint vars: true /
globals: 设置全局变量的处理， eg: / global MY_LIB: false /
exported: 告诉JSHint，当前文件会导出一些全局变量。 eg:/ exported EXPORTED_LIB /
ignore: 忽略一些代码，可忽略一段代码，也可忽略仅一行。 eg： // Code here will be linted with JSHint. / jshint ignore:start / // Code here will be linted with ignored by JSHint. / jshint ignore:end /
ignoreThis(); // jshint ignore:line
基本上来说，JSHint对于可配置性的处理非常完善，但是不得不说的是，其也让整个配置规则看起来比较复杂。
和Gulp集成
社区的力量是无穷的，目前个人最偏好的前端构建工具是Gulp，而JSHint可以非常方便的与Gulp集成，从而让前端的整个构建看起来更加的统一，不要一会执行JSHint任务，一会儿又是Gulp任务。
首先，安装JSHint的Gulp插件：
然后，编写运行JSHint的任务
就是这么简单。
JSHint： https://github.com/jshint/jshint/
gulp-jshint： https://github.com/spenceralger/gulp-jshint
2008年，Douglas Crockford大神写完《JavaScript:The Good Parts》 http://book.douban.com/subject/11874748/ 之后，给JavaScript树立了一个完整的技术规范,算是给JavaScript正名了（设计还是可以的，关键是要用好）。然后他老人家心想说：“老子告诉你们什么是好的JavaScript了，再送你们一个检测工具吧，凡是过不了我规范就不是好的JavaScript代码，Warning: JSLint will hurt your feelings”。当然除了最后Warning那句，其它都是我YY的。总之，就是老头根据自己的理念用JavaScript写了一个JavaScript代码规范检查工具，这就是JSLint（http://www.jslint.com/），后来非常流行，也的确帮助了广大的JavaScript程序员。但是因为这老头的个性既霸道又固执（很多大神貌似都这样子...），对于自己的代码规范不做丝毫的妥协，对开源社区的反馈的回应也很不礼貌。（ https://raw.githubusercontent.com/disqus/disqus.github.com/master/_posts/2011-02-20-antonkovalyov-why-i-forked-jslint-to-jshint.html） 于是，JSLint从一个帮助程序员规范代码，避免Bug的工具，变成了一个让你写的代码像Crockford的工具。在最不信神的IT界，这当然不能忍了。 2011年，一个叫Anton Kovalyov的前端程序员借助开源社区的力量弄出来了JSHint，其思想基本上和JSLint是一致的，但是其有一下几项优势：
- 可配置规则，每个团队可以自己定义自己想要的代码规范。
- 对社区非常友好，社区支持度高。几乎所有的主流编辑器，IDE都有了JSHint的插件，前端构建工具Grunt，Gulp也都有其插件，另外还有很多基于JSHint的酷炫小项目，参见：http://www.jshint.com/install/。
- 可定制的结果报表。做CI的时候就方便美观多了。
安装，使用
还是情不自禁的啰嗦一下，在我看来，Node最大的功绩不在于让JavaScript可以写后台程序，而在于其繁荣了整个前端开源社区。在Node环境下，安装JSHint非常简单：
npm install jshint (-g)
然后就可以通过如下的命令检测代码
jshint ./app/model.js
默认情况下会得到如下的结果
./app/model.js: line 27, col 2, Missing semicolon.
配置与规则
前面已经提到，JSHint最大的优势在于其可配置性。JSHint的确提供了非常细致的配置规则。
开发者可以通过3种方式指定团队的代码规范：
运行时通过--config指定配置文件。
使用特殊的文件名.jshintrc, 运行时jshint会从当前路径下开始，一层一层往上找。
自己把规则配置到项目的package.json中，放置到属性名jshintConfig下。
JSHint的config文件就是一个json文件，里面配置的就是一堆的JSHint规则， 如下：
{
"undef": true,
"unused": true,
"predef": [ "MY_GLOBAL" ]
}
例子中的配置规则要求：
- “undef”: 所有使用的变量都必须已定义
- “unused”: 所有定义的变量都必须被使用
- “predef”: 这些变量已定义，检查时不用检测其是否已定义
JSHint配置文件中的规则有3类：
- Enforcing: 这些规则被置为true，JSHint会对代码进行更严格的检查。
- Relaxing: 这些规则被置为true，JSHint会容忍规则中定义的情况出现。
- Environment: 这些规则被置为true，JSHint会认为代码默认有一些全局变量。
JSHint支持的所有规则,以及每个规则的值应该怎么填。参见： http://www.jshint.com/docs/options/。
前面提到了可以通过配置文件指定项目中的JavaScript代码需要遵守的规则，但是在实际项目中，存在某个文件需要特别的处理，或者是某个文件的某个方法需要特别的宽容的情况，对于这种情况，JSHint提供了一些指令内嵌到JavaScript代码中，在JSHint检查的时候会根据指令进行处理。JSHint提供的指令有：
jshint:设置JSHint规则，eg：/ jshint strict: true /
jslint: 设置JSHint兼容的JSLint规则，eg: / jslint vars: true /
globals: 设置全局变量的处理， eg: / global MY_LIB: false /
exported: 告诉JSHint，当前文件会导出一些全局变量。 eg:/ exported EXPORTED_LIB /
ignore: 忽略一些代码，可忽略一段代码，也可忽略仅一行。 eg： // Code here will be linted with JSHint. / jshint ignore:start / // Code here will be linted with ignored by JSHint. / jshint ignore:end /
ignoreThis(); // jshint ignore:line
基本上来说，JSHint对于可配置性的处理非常完善，但是不得不说的是，其也让整个配置规则看起来比较复杂。
和Gulp集成
社区的力量是无穷的，目前个人最偏好的前端构建工具是Gulp，而JSHint可以非常方便的与Gulp集成，从而让前端的整个构建看起来更加的统一，不要一会执行JSHint任务，一会儿又是Gulp任务。
首先，安装JSHint的Gulp插件：
npm install gulp-jshint --save-dev
然后，编写运行JSHint的任务
var jshint = require('gulp-jshint');
gulp.task('hint', function () {
gulp.src('./app/*.js')
.pipe(jshint())
.pipe(jshint.reporter('default'));
});
然后，只需要运行gulp hint即可检查代码。
就是这么简单。
JSHint： https://github.com/jshint/jshint/
gulp-jshint： https://github.com/spenceralger/gulp-jshint