(编辑) 以下答案经过编辑。我把下面的原始答案留给上下文(否则这些评论就没有意义了)。

当这个问题最初被问到时，JSLint是JavaScript的主要检测工具。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不喜欢的事情实际上是正确的事情。

几个星期前我也有同样的问题，当时我正在评估JSLint和JSHint。

与这个问题的答案相反，我的结论不是:

务必使用JSLint。

Or:

如果您正在为自己或团队寻找一个非常高的标准，JSLint。

因为你可以在JSHint和JSLint中配置几乎相同的规则。所以我认为你所能实现的规则并没有太大的不同。

因此，选择一个而不是另一个的原因更多是政治上的，而不是技术上的。

我们最终决定使用JSHint，原因如下:

似乎比JSLint更可配置。 看起来更像是社区驱动的，而不是一个人的表演(不管这个男人有多酷)。 JSHint比JSLint更符合我们的代码风格OOTB。

我要提出第三个建议，谷歌闭包编译器(也是闭包Linter)。你可以在这里在线试用。

闭包编译器是一个让JavaScript下载和运行更快的工具。它是一个真正的JavaScript编译器。它不是从源语言编译到机器代码，而是从JavaScript编译到更好的JavaScript。它解析你的JavaScript，分析它，删除死代码，重写并最小化剩下的代码。它还检查语法、变量引用和类型，并警告常见的JavaScript陷阱。

(编辑) 以下答案经过编辑。我把下面的原始答案留给上下文(否则这些评论就没有意义了)。

当这个问题最初被问到时，JSLint是JavaScript的主要检测工具。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不喜欢的事情实际上是正确的事情。

前言:嗯，事态迅速升级。但我决定挺过去。希望这个答案对你和其他读者有所帮助。

代码提示

虽然JSLint和JSHint是很好的工具，但多年来，我开始欣赏我的朋友@ugly_syntax调用:

较小的设计空间。

这是一个普遍的原则，就像一个“禅僧”，限制一个人必须做出的选择，一个人可以更有成效和创造性。

因此，我目前最喜欢的零配置JS代码风格:

StandardJS。

更新:

流动有了很大的改善。有了它，你 可以添加类型到你的JS与将帮助你防止很多 的病菌。但它也可以不碍事，比如 在接口非类型化JS时。试试吧!

快速入门/ TL

将标准作为依赖项添加到项目中

npm install --save standard

然后是包装。Json，添加以下测试脚本:

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

在开发过程中，如果想要更时髦的输出，请运行npm install——global snzy，而不是运行npm test。

注意:类型检查与启发式

我的朋友在提到设计空间时提到了Elm，我鼓励你尝试一下这种语言。

为什么?JS实际上是受到LISP的启发，LISP是一种特殊的语言，恰好是非类型化的。Elm或Purescript等语言是类型函数式编程语言。

输入限制你的自由，以便编译器能够检查和指导你，当你最终违反语言或你自己的程序的规则;不管程序的大小(LOC)如何。

最近，我们有一位初级同事实现了两次响应式接口:一次在Elm中，一次在React中;来看看我在说什么吧。

主要进行比较。Elm(有型)⇔index.js(无型，无测验)

(注:React代码不是惯用的，可以改进)

最后一点，

事实上JS是无类型的。我凭什么向你推荐类型化编程?

看，有了JS，我们处在一个不同的领域:从类型中解放出来，我们可以轻松地表达那些很难或不可能给出正确类型的东西(这当然是一个优势)。

但是如果没有类型，我们的程序就无法得到控制，所以我们不得不引入测试和(在较小范围内)代码样式。

我建议你从LISP(例如ClojureScript)中寻找灵感，并投资于测试你的代码。阅读子堆栈的方式，以获得一个想法。

和平。

好吧，而不是做手动lint设置，我们可以包括所有的lint设置在我们的JS文件本身的顶部。

在该文件中声明所有的全局变量，如下所示:

/*global require,dojo,dojoConfig,alert */

像这样声明所有的lint设置:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

希望这对你有帮助:)