English 我目前正在针对JSLint验证我的JavaScript并取得进展，它正在帮助我编写更好的JavaScript，尤其是在使用Jquery库时。
现在我所遇到JSHint，一个叉的JSLint。
因此，我想知道对于Web应用程序来说，它是JavaScript的主要驱动力，它是可用于以下工作的更好或最适用的验证工具：
我现在想确定一种验证机制并继续前进，将其用于客户端验证。
和jshint和jslint之间的区别？请在单个javascript示例中说明。
链接：
jshint - http://www.jshint.com/
jslint - http://jslint.com/
还有另一个积极开发的替代方法-JSCS — JavaScript代码样式：
JSCS是用于以编程方式执行样式指南的代码样式样式。您可以使用150多种验证规则为项目详细配置JSCS，其中包括来自流行样式指南（如jQuery，Airbnb，Google等）的预设。
它带有多个预设，您可以通过简单地preset在.jscsrc配置文件中指定并对其进行自定义来进行选择-覆盖，启用或禁用任何规则：
{
"preset": "jquery",
"requireCurlyBraces": null
}
也有为流行的编辑器构建的插件和扩展。
另请参阅：
我会提出第三个建议，即Google Closure编译器（以及Closure Linter）。您可以在此处在线尝试。
Closure Compiler是使JavaScript下载和运行速度更快的工具。这是一个真正的JavaScript编译器。它不是从源语言编译为机器代码，而是从JavaScript编译为更好的JavaScript。它解析您的JavaScript，对其进行分析，删除无效代码，然后重写并最大程度地减少剩余内容。它还会检查语法，变量引用和类型，并警告常见的JavaScript陷阱。
几周前我遇到了同样的问题，并且正在评估JSLint和JSHint。
与这个问题的答案相反，我的结论不是：
一定要使用JSLint。
要么：
如果您正在为自己或团队寻求一个很高的标准，那么JSLint。
由于您可以在JSHint中配置与在JSLint中几乎相同的规则。因此，我认为可以实现的规则没有太大差异。
因此，选择一个以上的原因更多是政治上的而不是技术上的。
由于以下原因，我们最终决定选择JSHint：
[编辑]
此答案已被编辑。我将下面的原始答案留给上下文（否则，注释将无意义）。
最初提出这个问题时，JSLint是JavaScript的主要整理工具。JSHint是JSLint的新分支，但尚未与原始版本相去甚远。
从那时起，JSLint几乎保持静态，而JSHint进行了很大的更改-它抛弃了JSLint的许多对立规则，增加了很多新规则，并且通常变得更加灵活。此外，现在可以使用另一个工具ESLint，它更加灵活并且具有更多规则选项。
在我最初的回答中，我说过您不应该强迫自己遵守JSLint的规则；只要您了解它为什么会发出警告，就可以自己判断是否更改代码以解决警告。
从2011年开始实施JSLint的超严格规则集，这是合理的建议-我见过很少有JavaScript代码集可以通过JSLint测试。但是，利用当今的JSHint和ESLint工具中可用的更为实用的规则，试图使您的代码以零警告通过它们是更现实的主张。
有时候，棉短绒有时仍会抱怨您故意做的事情-例如，您知道应该始终使用，===但只有这一次您才有充分的理由使用==。但是即使那样，使用ESLint，您也可以选择eslint-disable在相关行周围进行指定，这样您仍然可以通过带有零警告的lint测试，其余代码则遵循该规则。（只是不要经常做这种事情！）
[原始答案]
一定要使用JSLint。但是不要迷恋结果，也不要纠结它警告的所有内容。这将帮助您改进代码，并帮助您查找潜在的错误，但并非JSLint抱怨的所有内容都是一个真正的问题，因此不必觉得您必须以零警告完成该过程。
不管写得多么好，几乎任何长度或复杂性都很高的Javascript代码都会在JSLint中产生警告。如果您不相信我，请尝试通过它运行一些流行的库，例如JQuery。
一些JSLint警告比其他警告更有价值：了解要注意的警告和不那么重要的警告。应该考虑每一个警告，但不必为了解决任何给定的警告而修正代码。查看代码并决定对它满意是完全可以的。有时候，JSlint不喜欢的事情实际上是正确的事情。
好吧，除了进行手动的lint设置外，我们还可以在JS文件本身的顶部包括所有lint设置，例如
声明该文件中的所有全局变量，例如：
声明所有的皮棉设置，例如：
希望对你有帮助 ：）