我目前正在针对 JSLint 验证我的 JavaScript 并取得进展，它帮助我编写更好的 JavaScript - 特别是在使用 Jquery 库时。
现在我所遇到JSHint，一个叉的JSLint。
所以我想知道对于 Web 应用程序来说，哪些是由 JavaScript 驱动的，它是更好或最适用的验证工具：
我想现在决定验证机制并继续前进，将其用于客户端验证。
jshint 和 jslint 之间的区别？请在单个 javascript 示例中解释。
链接：
jshint - http://www.jshint.com/
jslint - http://jslint.com/
使用JSLint的，如果你正在寻找一个非常高的标准为自己或你的团队，但请记住，这是不一定的标准，只有一个标准，其中一些由道格·克罗克福德教条来给我们。
如果您想要更灵活一点，或者您的团队中有一些不认同 JSLint 意见的老专家，或者经常在 JavaScript 和其他 C 系列语言之间来回切换，请尝试 JSHint。
两篇关于 fork 背后的推理的文章解释了 JSHint 存在的原因：
JSLint 背后的理念是它是社区驱动的，而不是 Crockford 驱动的。JSHint 通常对 JSLint 坚持的一些风格和次要的语法意见更宽容（或至少可配置或不可知）。
例如，如果您认为下面的1.和2.都很好，或者如果您想编写具有1.的一个或多个方面而在2.中不可用的代码，则 JSHint 适合您。如果您认为2.是唯一正确的选项，请使用 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);
}
})();
通过 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-loopvar i = 0声明，以及函数声明的一些空白强制执行。
JSLint 强制执行的一些空白内容不一定是坏的，但只是与家族中其他语言（C、Java、Python 等）的一些非常标准的空白约定不同步，通常也作为 Javascript 中的约定遵循。由于我一整天都在用这些语言编写各种语言，并且与不喜欢我们代码中的 Lint 风格空白的团队成员一起工作，我发现 JSHint 是一个很好的平衡。它捕获合法的错误和格式非常糟糕的代码，但不会像 JSLint 那样（有时，以我无法禁用的方式）对我不关心的风格意见或句法挑剔对我吠叫。
许多好的库都不是 Lint'able，这对我来说表明，有些 JSLint 只是推送一个版本的“好代码”（确实是好代码）的想法是有道理的。但是话又说回来，相同的库（或其他好的库）也可能无法提示，所以，touché。
[编辑]
此答案已被编辑。我将在下面留下原始答案以供参考（否则评论将毫无意义）。
当最初提出这个问题时，JSLint 是 JavaScript 的主要 linting 工具。JSHint 是 JSLint 的一个新分支，但与原始版本没有太大区别。
从那时起，JSLint 几乎保持不变，而 JSHint 发生了很大的变化——它抛弃了 JSLint 的许多对抗性规则，添加了大量新规则，并且总体上变得更加灵活。此外，另一个工具 ESLint 现在可用，它更加灵活并且具有更多规则选项。
在我原来的回答中，我说你不应该强迫自己遵守 JSLint 的规则；只要你明白它为什么会抛出警告，你就可以自己判断是否更改代码来解决警告。
对于 2011 年的 JSLint 超严格规则集，这是一个合理的建议——我见过很少有 JavaScript 代码集可以通过 JSLint 测试。然而，随着当今 JSHint 和 ESLint 工具中可用的更实用的规则，尝试让您的代码以零警告通过它们是一个更现实的主张。
偶尔可能仍然存在 linter 会抱怨您故意做的事情的情况 - 例如，您知道应该始终使用 ，===但只有这一次您有充分的理由使用==. 但即便如此，使用 ESLint，您可以选择eslint-disable在有问题的行周围指定，这样您仍然可以通过零警告的 lint 测试，而您的其余代码遵守规则。（只是不要经常做那种事情！）
[原答案如下]
一定要使用 JSLint。但是不要被结果和修复它警告的所有内容所困扰。它会帮助你改进你的代码，它会帮助你找到潜在的错误，但并不是 JSLint 抱怨的一切都是一个真正的问题，所以不要觉得你必须在零警告的情况下完成这个过程。
几乎任何具有任何显着长度或复杂性的 Javascript 代码都会在 JSLint 中产生警告，无论它写得多么好。如果您不相信我，请尝试通过它运行一些流行的库，例如 JQuery。
一些 JSLint 警告比其他警告更有价值：了解哪些需要注意，哪些不太重要。应该考虑每个警告，但不要觉得有义务修复您的代码以清除任何给定的警告；查看代码并决定对它感到满意是完全可以的；有时 JSlint 不喜欢的事情实际上是正确的做法。
在 javascript linting 前端还有另一个成熟且积极开发的“播放器” - ESLint：
ESLint 是一种用于识别和报告在 ECMAScript/JavaScript 代码中发现的模式的工具。在许多方面，它类似于 JSLint 和 JSHint，但有一些例外：
- ESLint 使用 Esprima 进行 JavaScript 解析。
- ESLint 使用 AST 来评估代码中的模式。
- ESLint 是完全可插拔的，每条规则都是一个插件，您可以在运行时添加更多规则。
这里真正重要的是它可以通过自定义插件/规则进行扩展。已经有多个为不同目的编写的插件。在别人，主要有：
而且，当然，您可以使用您选择的构建工具来运行ESLint：
几周前我遇到了同样的问题，正在评估 JSLint 和 JSHint。
与这个问题的答案相反，我的结论不是：
一定要使用 JSLint。
或者：
如果您正在为自己或团队寻找一个非常高的标准，JSLint。
因为您可以在 JSHint 中配置与在 JSLint 中几乎相同的规则。所以我认为你可以实现的规则没有太大区别。
因此，选择一个而不是另一个的原因更多的是政治而不是技术。
我们最终决定使用 JSHint，原因如下：
我会提出第三个建议，Google Closure Compiler（以及Closure Linter）。您可以在此处在线试用。
Closure Compiler 是一个让 JavaScript 下载和运行速度更快的工具。它是一个真正的 JavaScript 编译器。它不是从源语言编译成机器码，而是从 JavaScript 编译成更好的 JavaScript。它解析您的 JavaScript，分析它，删除死代码并重写和最小化剩下的代码。它还检查语法、变量引用和类型，并对常见的 JavaScript 陷阱发出警告。