javaScript语法和风格的检查工具
一、JSLint、 JSHint、 JSCS、 ESLint
1、JSLint是由Douglas Crockford开发的，可能是最早的JavaScript Lint工具。JSLint定义了一组编码约定，这比ECMA定义的语言更为严格。
var jslint = require('gulp-jslint'), gulp = require('gulp'); gulp.task('jslint', function () { return gulp.src([ './controllers/*.js', './models/*.js', './*.js' ]).pipe(jslint({ node: true, nomen: true, sloppy: true, plusplus: true, unparam: true, stupid: true })); }); gulp.task('default', ['jslint’]);
2、JSHint是由Anton Kovalyov基于JSLint的代码实现的开源项目，由于JSLint时期大多数人都在受JSLint压迫，JSHint相比较之下，更友好，也更容易配置。但是，由于它是基于JSLint开发的，自然原有的一些问题它也继承下来了，比如不易扩展，不容易直接根据报错定位到具体的规则配置等。好在它发展的不错，很多时候遇到的问题都可以在网上找到相关的解决方案，而且文档也是非常不错的。对javaScript语法和风格的检查工具，但检查不出逻辑问题
3、JSCS不同于其他，因为如果不给它一个配置文件或告诉它一个配置项，JSCS不会做任何事情。可以存他们的网站现在配置项，所以这不是个大问题，并且有许多配置项，例如jQuery代码风格配置项、Google配置项。它有超过90个不同的规则，通过插件可以创建自定义规则。当和其他工具集成需要特定格式时，JSCS也支持自定义报告使得变得非常容易。JSCS是一个代码风格检查器。这意味着它仅仅匹配代码格式的问题，不匹配潜在的bugs、errors。因此，跟其他工具相比缺少灵活性，但是如果你仅仅强制检查代码风格，JSCS也是一个好的工具。
4、ESLint是由Nicholas C. Zakas在2013年开始开发的，它的初衷就是为了能让开发者能自定义自己的linting rules，而且它提供了一套相当完善的插件机制，可以自由的扩展，动态加载配置规则，同时可以方便的根据报错定位到具体的规则配置。而且我比较喜欢它的一点是文档非常详细，可能这也是灵活所必须的吧。在这里还要提一点，ESLint最初并不是为了造一个重复的轮子，而是作者在实际使用中的需求没有能得到JSHint团队的回应，所以他就结合当时的JSHint和另一个代码风格的检查工具JSCS写出来了现在具备代码风格检查，自定义插件扩展功能的ESLint了。
二、比较
JSLint
优点
- 配置是老道已经定好的，开箱即用。
- 有限的配置选项，很多规则不能禁用
- 规范严格，凡是不符合老道所认为的好的风格的，都会有警告(这一项就看你是否完全认同老道了)
- 扩展性差
- 无法根据错误定位到对应的规则
JSHint
优点- 有了很多参数可以配置
- 支持配置文件，方便使用
- 支持了一些常用类库
- 支持了基本的ES6
- 不支持自定义规则
- 无法根据错误定位到对应的规则
JSCS
优点
- 支持自定义报告，更容易与其他工具集成
- 如果你遵循一种可用的代码风格，配置项和准备好的配置文件使其容易启动
- 在报告中存在标记包含规则名字，所以很容易指出哪个规则造成了错误
- 通过自定义插件进行拓展
不足
- 仅仅检查代码风格的问题。JSCS不检查潜在存在的bugs，例如不适用的变量、偶然的全局变量等等
- 四个工具中最慢，但是在使用中不是一个问题
ESLint
优点- 默认规则里面包含了JSLint和JSHint的规则，易于迁移(这肯定是故意的XD)
- 可配置为警告和错误两个等级，或者直接禁用掉
- 支持插件扩展
- 可以自定义规则
- 可以根据错误定位到对应的规则
- 支持ES6
- 唯一一个支持JSX的工具
- 支持自定义报告
- 需要进行一些自定义配置(因为太灵活了嘛，不过文档是很详细的)
- 慢 (它比其他两个都要慢)
相比较而言ESLint更具优势。JSHint是严格和不可配置的，而JSHint缺少拓展机制。JSCS如果仅仅用于代码风格检验是一个好的选择，但是ESLint不仅可以进行代码风格的检验，而且可以检查代码中的bug和其他问题。
JSHint是第二选择。如果不需要ESLint先进的特点，JSHint一旦配置就可以捕获需要好的问题。带有许多规则的JSCS，如果出了代码风格外不进行其他检查，将是一个好的选择。
