458

我目前正在针对 JSLint 验证我的 JavaScript 并取得进展，它帮助我编写更好的 JavaScript - 特别是在使用 Jquery 库时。

我现在遇到了JSHint，它是JSLint的一个分支。
所以我想知道 Web 应用程序，它们很大程度上是由 JavaScript 驱动的，这是更好或最适用的验证工具：

  • JSLint 还是 JSHint？

我现在想决定一个验证机制并继续前进，将其用于客户端验证。

以及 jshint 和 jslint 之间的区别？请在单个 javascript 示例中进行解释。

链接：

  1. jshint - http://www.jshint.com/

  2. jslint - http://jslint.com/

4

8 回答 8

370

TL;博士

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

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

完整版本

两篇关于分叉背后原因的文章解释了 JSHint 存在的原因：

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

  2. 为什么我将 JSLint 分叉到 JSHint

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

例如，如果您认为下面的1.和2.都很好，或者如果您想编写具有1.中的一个或多个方面的代码2.，则 JSHint 适合您。如果您认为2.是唯一正确的选项，请使用 JSLint。我敢肯定还有其他差异，但这突出了一些。

  1. 通过 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);
  }
})();

  2. 通过 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 代码更具视觉吸引力。我不同意它的唯一特征是它讨厌函数中的多个声明和-loop声明varforvar i = 0，以及函数声明的一些空白强制。

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

很多好的库都不是 Lint'able，这对我来说证明了一些 JSLint 只是推送一个版本的“好代码”（这确实是好代码）的想法是有道理的。但话又说回来，相同的库（或其他好的库）可能也不是 Hint'able，所以，touché。

于 2012-05-26T04:36:08.910 回答
158

[编辑]
此答案已被编辑。我将在下面留下原始答案以获取上下文（否则评论将没有意义）。

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

于 2011-07-23T22:00:33.090 回答
61

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

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

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

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

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

于 2014-12-23T06:20:38.197 回答
18

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

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

一定要使用 JSLint。

或者：

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

因为您可以在 JSHint 中配置与 JSLint 中几乎相同的规则。因此，我认为您可以实现的规则没有太大差异。

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

由于以下原因，我们最终决定使用 JSHint：

  • 似乎比 JSLint 更具可配置性。
  • 看起来肯定更受社区驱动，而不是单人表演（不管The Man有多酷）。
  • JSHint 比 JSLint 更符合我们的代码风格 OOTB。
于 2014-12-22T14:45:16.740 回答
13

我会提出第三个建议，Google Closure Compiler（以及Closure Linter）。你可以在这里在线试用。

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

于 2011-07-23T21:07:42.813 回答
13

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

我在这里有点得意忘形

代码提示

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

更小的设计空间。

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

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

标准JS。

更新：

流量进步了很多。有了它，您可以将类型添加到您的 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（输入）⇔ index.js（未输入，无测试）

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

最后一句话，

现实情况是 JS是无类型的。我向谁推荐类型化编程？

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

但是没有类型，我们的程序就没有什么可以检查的了，所以我们不得不引入测试和（在较小的范围内）代码样式。

我建议您查看 LISP（例如ClojureScript）以获得灵感并投资于测试您的代码。阅读子堆栈的方式以获得一个想法。

和平。

于 2016-01-23T18:23:46.270 回答
8

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

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

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

声明所有 lint 设置，例如：

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

希望对你有帮助 ：）

于 2014-09-17T13:02:12.280 回答
1

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

JSCS 是一种代码样式 linter，用于以编程方式强制执行您的样式指南。您可以使用超过 150 条验证规则为您的项目详细配置 JSCS，包括来自流行样式指南（如 jQuery、Airbnb、Google 等）的预设。

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

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

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

另见：

于 2015-08-25T15:58:33.630 回答