我应该使用JSLint还是JSHint JavaScript验证？
我目前正在验证我的JavaScript和JSLint并取得进展，它帮助我编写更好的JavaScript - 特别是在使用Jquery库时。
现在我所遇到JSHint，JSLint的的一个分支。
所以我很想知道Web应用程序，这是非常多的JavaScript驱动，这是更好或最适用的验证工具来处理：
我想现在决定验证机制并向前推进，将其用于客户端验证。
jshint和jslint之间的区别？ 请在单个javascript例子中解释。
链接：
jshint - http://www.jshint.com/
jslint - http://jslint.com/
[编辑]
这个答案已被编辑。 我将下面的原始答案留在上下文中（否则评论无效）。
当最初提出这个问题时，JSLint是JavaScript的主要工具。 JSHint是JSLint的一个新分支，但与原始版本没有多大差异。
从那以后，JSLint一直保持静态，而JSHint已经发生了很大的变化 - 它抛弃了JSLint的更多对抗性规则，增加了大量新规则，并且通常变得更加灵活。 另外，现在可以使用另一个工具ESLint，它更加灵活并且有更多的规则选项。
在我最初的回答中，我说过你不应该强迫自己坚持JSLint的规则; 只要你明白为什么要发出警告，你就可以自己判断是否改变代码来解决警告。
使用2011年JSLint的超严格规则集，这是合理的建议 - 我已经看到很少可以通过JSLint测试的JavaScript代码集。 然而，在今天的JSHint和ESLint工具中使用更实用的规则，尝试通过零警告让你的代码通过它们是一个更现实的命题。
有时候偶尔会有一些情况，linter会抱怨你有意做的事 - 例如，你知道你应该总是使用===但是这只是你有一个很好的理由使用== 。 但即使如此，在ESLint中，您可以选择在有问题的线路周围指定eslint-disable ，这样您仍可以通过零警告进行传递lint测试，其余代码遵守规则。 （只是不要经常这样做！）
[原文如下]
通过一切手段使用JSLint。 但是不要挂在结果上，并且要修复它警告的所有事情。 它会帮助你改进你的代码，它会帮助你找到潜在的错误，但并不是所有JSLint抱怨的事情都会成为一个真正的问题，所以不要觉得你必须完成零过程的警告。
几乎任何具有任何长度或复杂性的Javascript代码都会在JSLint中产生警告，无论它写得多么好。 如果您不相信我，请尝试通过它运行一些流行的库，如JQuery。
一些JSLint警告比其他警告更有价值：学习哪些警告，哪些警告不那么重要。 应该考虑每一个警告，但不要认为有必要修复你的代码来清除任何给定的警告; 查看代码并确定您对此感到满意是完全可以的; 有时候JSlint不喜欢的东西实际上是正确的。
tl; dr外卖：
如果你正在为自己或团队寻找非常高的标准，JSLint。 但它不一定是标准，只是一个标准，其中的一些标准来自一位名叫Doug Crockford的javascript神。 如果你想变得更加灵活一些，或者在团队中有一些老的专业人员不会购买JSLint的意见，或者定期在JS和其他C系列语言之间来回切换，请尝试JSHint。
长版：
为什么JSHint存在：叉子的原因很好地解释了：
http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to -jshint /
所以我想这个想法是它是“社区驱动的”而不是克罗克福德驱动的。 实际上，JSHint通常比JSLint坚持的少数语法和次要语法“意见”要宽松一些（或至少可配置或不可知）。
举个例子，如果你认为下面的A和B都是好的，或者如果你想编写一个或多个B中不可用的方面的代码，JSHint就是为你准备的。 如果你认为B是唯一正确的选择...... JSLint。 我相信还有其他的不同之处，但是这突出了一些。
答）通过JSHint开箱 - 失败JSLint
(function() {
"use strict";
var x=0, y=2;
function add(val1, val2){
return val1 + val2;
}
var z;
for (var i=0; i<2; i++){
z = add(y, x+i);
}
})();
B）通过JSHint和JSLint
(function () {
"use strict";
var x = 0, y = 2, i, z;
function add(val1, val2) {
return val1 + val2;
}
for (i = 0; i < 2; i += 1) {
z = add(y, x + i);
}
}());
就我个人而言，我发现JSLint代码非常好看，我不同意的唯一难点在于它对函数中多个var声明的仇恨以及for循环var i = 0声明和一些空白函数声明的强制执行。
JSLint强制执行的一些空白事物，我发现不一定是坏的，但与家族中其他语言（C，Java，Python等）的一些非常标准的空白约定不同步在Javascript中也遵循惯例。 由于我一天中以各种不同的语言编写，并且与不喜欢Lint风格的空白代码的团队成员一起工作，我发现JSHint是一个很好的平衡。 它捕获的东西是一个合法的错误或非常糟糕的形式，但并不像JSLint那样对我咆哮（有时，我无法禁用），因为我不喜欢它的文体观点或语法挑剔。
许多优秀的库不是Lint'able的，这对我来说证明了一些JSLint仅仅是推送1个“好代码”（实际上是好代码）的观点。 但是，再次，相同的图书馆（或其他好的图书馆）可能也不是可靠的，所以，touché。
在javascript ESLint前端还有另一个成熟和积极开发的“玩家” - ESLint ：
ESLint是识别和报告ECMAScript / JavaScript代码中发现的模式的工具。 在很多方面，它与JSLint和JSHint类似，但有一些例外：
这里真正重要的是它可以通过自定义插件/规则进行扩展 。 已经有多个插件用于不同的目的。 其中包括：
当然，您可以使用您选择的构建工具来运行ESLint ：
上一篇: Should I use JSLint or JSHint JavaScript validation?
下一篇: UIKit Dynamics UICollisionBehavior collision without bounce