我应该使用 JSLint 还是 JSHint JavaScript 验证？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

5 年前已关闭。

Answer 1

好吧，我们可以在 JS 文件本身的顶部包含所有 lint 设置，而不是进行手动 lint 设置，例如

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

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

声明所有 lint 设置，如：

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

希望这会帮助你:)

Answer 2

还有另一种积极开发的替代方案 - JSCS — JavaScript 代码风格：

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

它带有多个预设，您只需在中指定预设即可从中进行选择.jscsrc 配置文件并对其进行自定义 - 覆盖、启用或禁用任何规则：

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

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

另请参阅：

• 完美代码，零工作量

Answer 3

TL;DR

如果您正在为自己或您的团队寻找非常高的标准，请使用 JSLint，但请记住，它不一定是标准标准，而只是一个标准，其中一些教条性的观点来自道格·克罗克福德（Doug Crockford）。

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

完整版

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

1. JSHint：社区驱动的 JSLint 分支

2. <一href="https://web.archive.org/web/20130819215629/http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/" rel="noreferrer ">为什么我将 JSLint 分叉为 JSHint

JSLint 背后的想法是它是社区驱动的，而不是 Crockford 驱动的。 JSHint 通常对 JSLint 所坚持的一些风格和次要语法观点更加宽容（或者至少是可配置的或不可知的）。

例如，如果您认为下面的 1. 和 2. 都可以，或者您想使用 1. 中的一个或多个来编写代码> 的方面在 2. 中不可用，JSHint 适合您。如果您认为 2. 是唯一正确的选项，请使用 JSLint。我确信还存在其他差异，但这突出了一些差异。

1. 直接通过 JSHint - 失败 JSLint

   (function() {
     “严格使用”；
     var x = 0，y = 2；
     函数添加（val1，val2）{
       返回值1+值2；
     }
     var z；
     for (var i=0; i<2; i++){
       z = 添加（y，x+i）；
     }
   })();
   

2. 同时通过 JSHint 和 JSLint

   (function () {
       “严格使用”；
       var x = 0, y = 2, i, z;
       函数添加（val1，val2）{
          返回值1+值2；
       }
       for (i = 0; i < 2; i += 1) {
           z = 添加（y，x + i）；
       }
   }());
   

我发现 JSLint 代码在视觉上更具吸引力。我不同意它的唯一功能是它的 讨厌函数中的多个 var 声明和 for-loop var i = 0 声明，以及一些空白强制执行函数声明。

JSLint 强制执行的一些空白并不一定是坏事，只是与家族中其他语言（C、Java、Python 等）的一些相当标准的空白约定不同步，这些约定也经常在 Javascript 中遵循。由于我整天都在使用各种语言进行编写，并且与不喜欢代码中 Lint 样式空白的团队成员一起工作，因此我发现 JSHint 是一个很好的平衡。它捕获合法的错误和格式非常糟糕的代码，但不会像 JSLint 那样对我咆哮（有时，以我无法禁用的方式）针对我不关心的风格意见或语法挑剔。

许多优秀的库都无法进行 Lint'able，这对我来说表明 JSLint 的某些内容只是为了推送“优秀代码”的一个版本（实际上是优秀代码）这一想法是有一定道理的。但话又说回来，相同的库（或其他好的库）可能也无法提示，所以，touché。

Answer 4

[编辑]
该答案已被编辑。我将在下面留下原始答案以供参考（否则评论就没有意义）。

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

Answer 5

javascript linting 前端还有另一个成熟且积极开发的“玩家” - ESLint :

ESLint 是一种用于识别和报告在以下内容中发现的模式的工具：
ECMAScript/JavaScript 代码。在很多方面，它与 JSLint 相似，
JSHint，但有一些例外：

• ESLint 使用 Esprima 进行 JavaScript 解析。
• ESLint 使用 AST 来评估代码中的模式。
• ESLint 是完全可插入的，每个
  单个规则是一个插件，您可以在运行时添加更多规则。

这里真正重要的是它可以通过自定义插件/规则进行扩展。已经有多个为不同目的而编写的插件。在其他中，有：

• eslint-plugin-angular （强制执行 John Papa 的 Angular 风格指南< 中的一些准则/a>)
• eslint-plugin-jasmine
• eslint-plugin-backbone

当然，您可以使用您选择的构建工具来运行 ESLint：

• grunt-eslint
• gulp -eslint

Answer 6

几周前我也有同样的问题，并且正在评估 JSLint 和 JSHint。

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

一定要使用 JSLint。

或者：

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

因为您可以在 JSHint 中配置与 JSLint 中几乎相同的规则。所以我认为你可以实现的规则没有太大区别。

因此，选择其中一种的原因更多是政治性的，而不是技术性的。

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

• 似乎比 JSLint 更易于配置。
• 看起来绝对更受社区驱动，而不是一个人表演（无论The Man有多酷）。
• JSHint 比 JSLint 更符合我们的代码风格 OOTB。

Answer 7

我提出第三个建议，Google Closure Compiler（以及 Closure Linter）。您可以在此处在线试用。

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

Answer 8

前言：嗯，事情升级得很快。但还是决定挺过去。希望这个答案对您和其他读者有所帮助。

代码提示

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

较小的设计空间。

这是一个普遍原则，就像一位“禅僧”一样，限制一个人必须做出的选择，一个人可以变得更有生产力和创造力。

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

StandardJS。

更新：

Flow 有了很大改进。有了它，你
可以向你的 JS 添加类型，这将帮助你避免很多
错误。但它也可以不妨碍你，例如
当连接非类型化 JS 时。尝试一下！

快速入门 / TL;DR

将 standard 添加为项目的依赖项

npm install --save standard

然后在 package.json 中添加以下测试脚本：

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

为了在开发时获得更流畅的输出，npm install --global snazzy 并运行它而不是 npm test。

注意：类型检查与启发式

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

为什么？事实上，JS 受到了 LISP 的启发，LISP 是一类特殊的语言，恰好是无类型。 Elm 或 Purescript 等语言是类型函数式编程语言。

类型限制你的自由，以便编译器能够在你最终违反语言或你自己的程序规则时检查和指导你；无论程序的大小 (LOC)。

最近，我们的一位初级同事两次实现了响应式接口：一次在 Elm 中，一次在 React 中；看看我在说什么。

比较 Main.elm< /a> （输入）⇔ index.js（无类型，无测试）

（ps. 请注意，React 代码不惯用，可以改进）

最后一点，

现实是JS 是无类型的。我凭什么向你推荐类型化编程？

看，使用 JS，我们处于不同的领域：摆脱了类型的束缚，我们可以轻松地表达难以或不可能给出正确类型的事物（这当然是一个优势）。

但是，如果没有类型，就无法控制我们的程序，因此我们被迫引入测试和（在较小范围内）代码样式。

我建议您查看 LISP（例如 ClojureScript）以获取灵感并投资于测试您的代码。阅读子堆栈的方式来了解一下。

和平。