我要提出第三个建议，谷歌闭包编译器(也是闭包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不喜欢的事情实际上是正确的事情。

博士TL;

如果您正在为自己或您的团队寻找一个非常高的标准，请使用JSLint，但请记住，它不一定是标准，只是一个标准，其中一些标准教条地来自Doug Crockford。

如果您想要更灵活一点，或者您的团队中有一些老专家不接受JSLint的观点，或者经常在JavaScript和其他c家族语言之间来回切换，请尝试JSHint。

完整版

有两篇文章解释了JSHint存在的原因:

JSHint: JSLint的一个社区驱动的分支 为什么我把JSLint分叉到JSHint

JSLint背后的理念是它是社区驱动的，而不是crockford驱动的。JSHint通常对JSLint坚持的一些风格和次要语法意见更宽容(或者至少是可配置的或不确定的)。

例如，如果你认为两者都是1。和2。下面是很好的，或者如果你想用1中的一个或多个来编写代码。在2中没有的方面。， JSHint是给你的。如果你认为2。是唯一正确的选择，使用JSLint。我相信还有其他不同之处，但这里突出了一些。

从盒子里传递JSHint - JSLint失败 (函数(){ “使用严格的”; Var x=0, y=2; 函数add(val1, val2){ 返回val1 + val2; ｝ var z; For (var i=0;我< 2;我+ +){ Z = add(y, x+i); ｝ }) (); 同时传递JSHint和JSLint (函数(){ “使用严格的”; Var x = 0, y = 2, i, z; 函数add(val1, val2) { 返回val1 + val2; ｝ For (i = 0;I < 2;I += 1) { Z = add(y, x + i); ｝ } ());

我发现JSLint代码在视觉上更吸引人。我唯一不同意的特性是它讨厌在一个函数中声明多个var，讨厌for-loop var I = 0声明，以及对函数声明的一些空格强制。

A few of the whitespace things that JSLint enforces are not necessarily bad but are just out of sync with some pretty standard whitespace conventions for other languages in the family (C, Java, Python, etc.) often followed as conventions in Javascript as well. Since I'm writing in various of these languages throughout the day and working with team members who don't like Lint-style whitespace in our code, I find JSHint to be a good balance. It catches legitimate bugs and very badly formed code, but doesn't bark at me like JSLint does (sometimes, in ways I can't disable) for the stylistic opinions or syntactic nitpicks that I don't care for.

很多好的库都不能使用Lint，这对我来说证明了JSLint只是推出一个版本的“好代码”(这确实是好代码)的想法是有道理的。但是，同样的库(或其他好的库)可能也不具备Hint'able，因此，touché。

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

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

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

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

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

希望这对你有帮助:)

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

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

务必使用JSLint。

Or:

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

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

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

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

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

在javascript检测方面，还有另一个成熟且积极开发的“播放器”——ESLint:

ESLint是一个用于识别和报告中发现的模式的工具 ECMAScript / JavaScript代码。在许多方面，它类似于JSLint和 JSHint有几个例外: ESLint使用Esprima进行JavaScript解析。 ESLint使用AST来计算代码中的模式。 ESLint是完全可插入的 单个规则是一个插件，你可以在运行时添加更多的规则。

这里真正重要的是它可以通过自定义插件/规则进行扩展。已经为不同的目的编写了多个插件。其中包括:

eslint-plugin-angular(强制执行John Papa的Angular风格指南中的一些指导方针) eslint-plugin-jasmine eslint-plugin-backbone

当然，你也可以使用你选择的构建工具来运行ESLint:

咕噜咕噜咕噜 古尔普-埃斯林特

还有另一个正在开发的替代方案- JSCS - JavaScript代码风格:

JSCS是一种代码风格检测器，用于以编程方式强制执行您的风格 指南。您可以使用over为您的项目详细配置JSCS 150条验证规则，包括流行风格指南中的预设 jQuery, Airbnb，谷歌等。

它带有多个预设，您可以通过简单地在.jscsrc配置文件中指定预设并自定义它-覆盖，启用或禁用任何规则来进行选择:

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

还有为流行编辑器构建的插件和扩展。

还看到:

完美的代码，零努力

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

代码提示

虽然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)中寻找灵感，并投资于测试你的代码。阅读子堆栈的方式，以获得一个想法。

和平。