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

Should I use JSLint or JSHint JavaScript validation?

提问by amateur

I am currently validating my JavaScript against JSLint and making progress on, it's assisting me to write better JavaScript - in particular in working with the Jquery library.

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

I have now come across JSHint, a fork of JSLint.
So I am wondering for web applications, which are very much JavaScript was driven, which is the better or most applicable validation tool to work against:

现在我所遇到JSHint，一个叉的JSLint。
所以我想知道对于 Web 应用程序来说，哪些是由 JavaScript 驱动的，哪个是更好或最适用的验证工具：

• JSLint or JSHint?

• JSLint 还是 JSHint？

I want to decide now on a validation mechanism and moving forward, use this for client side validation.

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

And Difference between jshint and jslint? Please explain in single javascript example.

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

Links:

链接：

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

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

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

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

采纳答案by Spudley

[EDIT]
This answer has been edited. I'm leaving the original answer below for context (otherwise the comments wouldn't make sense).

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

When this question was originally asked, JSLint was the main linting tool for JavaScript. JSHint was a new fork of JSLint, but had not yet diverged much from the original.

当最初提出这个问题时，JSLint 是 JavaScript 的主要 linting 工具。JSHint 是 JSLint 的一个新分支，但与原来的没有太大区别。

Since then, JSLint has remained pretty much static, while JSHint has changed a great deal - it has thrown away many of JSLint's more antagonistic rules, has added a whole load of new rules, and has generally become more flexible. Also, another tool ESLint is now available, which is even more flexible and has more rule options.

从那以后，JSLint 几乎保持不变，而 JSHint 发生了很大的变化——它抛弃了 JSLint 的许多对抗性规则，添加了大量新规则，并且总体上变得更加灵活。此外，另一个工具 ESLint 现在可用，它更加灵活并且具有更多规则选项。

In my original answer, I said that you should not force yourself to stick to JSLint's rules; as long as you understood why it was throwing a warning, you could make a judgement for yourself about whether to change the code to resolve the warning or not.

在我原来的回答中，我说你不应该强迫自己遵守 JSLint 的规则；只要你明白它为什么会抛出警告，你就可以自己判断是否更改代码来解决警告。

With the ultra-strict ruleset of JSLint from 2011, this was reasonable advice -- I've seen very few JavaScript codesets that could pass a JSLint test. However with the more pragmatic rules available in today's JSHint and ESLint tools, it is a much more realistic proposition to try to get your code passing through them with zero warnings.

对于 2011 年的 JSLint 超严格规则集，这是一个合理的建议——我见过很少的 JavaScript 代码集可以通过 JSLint 测试。然而，随着当今 JSHint 和 ESLint 工具中可用的更实用的规则，尝试让您的代码以零警告通过它们是一个更现实的主张。

There may still occasionally be cases where a linter will complain about something that you've done intentionally -- for example, you know that you should always use ===but just this one time you have a good reason to use ==. But even then, with ESLint you have the option to specify eslint-disablearound the line in question so you can still have a passing lint test with zero warnings, with the rest of your code obeying the rule. (just don't do that kind of thing too often!)

偶尔可能仍然存在 linter 会抱怨您故意做的事情的情况 - 例如，您知道应该始终使用 ，===但只有这一次您有充分的理由使用==. 但即便如此，使用 ESLint，您可以选择eslint-disable在有问题的行周围指定，这样您仍然可以通过零警告的 lint 测试，而您的其余代码遵守规则。（只是不要经常做那种事情！）

---

---

[ORIGINAL ANSWER FOLLOWS]

[原答案如下]

By all means use JSLint. But don't get hung up on the results and on fixing everything that it warns about. It will help you improve your code, and it will help you find potential bugs, but not everything that JSLint complains about turns out to be a real problem, so don't feel like you have to complete the process with zero warnings.

一定要使用 JSLint。但是不要被结果和修复它警告的所有内容所困扰。它会帮助你改进你的代码，它会帮助你找到潜在的错误，但并不是 JSLint 抱怨的一切都是一个真正的问题，所以不要觉得你必须在零警告的情况下完成这个过程。

Pretty much any Javascript code with any significant length or complexity will produce warnings in JSLint, no matter how well written it is. If you don't believe me, try running some popular libraries like JQuery through it.

几乎任何具有任何显着长度或复杂性的 Javascript 代码都会在 JSLint 中产生警告，无论它写得多么好。如果您不相信我，请尝试通过它运行一些流行的库，例如 JQuery。

Some JSLint warnings are more valuable than others: learn which ones to watch out for, and which ones are less important. Every warning should be considered, but don't feel obliged to fix your code to clear any given warning; it's perfectly okay to look at the code and decide you're happy with it; there are times when things that JSlint doesn't like are actually the right thing to do.

一些 JSLint 警告比其他警告更有价值：了解哪些需要注意，哪些不太重要。应该考虑每个警告，但不要觉得有必要修复您的代码以清除任何给定的警告；查看代码并决定对它感到满意是完全可以的；有时 JSlint 不喜欢的事情实际上是正确的做法。

回答by Ben Roberts

tl;dr takeaway:

tl;博士外卖：

If you're looking for a very high standard for yourself or team, JSLint. But its not necessarily THE standard, just A standard, some of which comes to us dogmatically from a javascript god named Doug Crockford. If you want to be a bit more flexible, or have some old pros on your team that don't buy into JSLint's opinions, or are going back and forth between JS and other C-family languages on a regular basis, try JSHint.

如果您正在为自己或团队寻找一个非常高的标准，JSLint。但它不一定是标准，只是一个标准，其中一些标准来自一位名叫 Doug Crockford 的 JavaScript 神教条。如果你想要更灵活一点，或者你的团队中有一些不认同 JSLint 观点的老专家，或者经常在 JS 和其他 C 系列语言之间来回切换，请尝试 JSHint。

long version:

长版：

The reasoning behind the fork explains pretty well why JSHint exists:

分叉背后的原因很好地解释了 JSHint 存在的原因：

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslinthttp://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to -jshint/

So I guess the idea is that it's "community-driven" rather than Crockford-driven. In practicality, JSHint is generally a bit more lenient (or at least configurable or agnostic) on a few stylistic and minor syntactical "opinions" that JSLint is a stickler on.

所以我想这个想法是“社区驱动”而不是克罗克福德驱动。实际上，对于 JSLint 坚持的一些风格和次要的语法“意见”，JSHint 通常更宽容（或至少可配置或不可知）。

As an example, if you think both the A and B below are fine, or if you want to write code with one or more of the aspects of A that aren't available in B, JSHint is for you. If you think B is the only correct option... JSLint. I'm sure there are other differences, but this highlights a few.

例如，如果您认为下面的 A 和 B 都很好，或者如果您想使用 A 的一个或多个方面在 B 中不可用来编写代码，那么 JSHint 适合您。如果您认为 B 是唯一正确的选项... JSLint。我确定还有其他差异，但这突出了一些差异。

A) Passes JSHint out of the box - fails JSLint

A) 开箱即用地传递 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);
  }
})();

B) Passes Both JSHint and JSLint

B) 同时通过 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);
    }
}());

Personally I find JSLint code very nice to look at, and the only hard features of it that I disagree with are its hatred of more than one var declaration in a function and of for-loop var i = 0declarations, and some of the whitespace enforcements for function declarations.

就我个人而言，我发现 JSLint 代码非常好看，我不同意它的唯一硬特性是它讨厌函数中的多个 var 声明和 for 循环var i = 0声明，以及函数声明的一些空白强制执行.

A few of the whitespace things that JSLint enforces, I find to be not necessarily bad, but out of sync with some pretty standard whitespace conventions for other languages in the family (C, Java, Python, etc...), which are 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 stuff that's a legitimate bug or really bad form, 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.

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

A lot of good libraries aren't Lint'able, which to me demonstrates that there's some truth to the idea that some of JSLint is simply just about pushing 1 version of "good code" (which is, indeed, good code). But then again, the same libraries (or other good ones) probably aren't Hint'able either, so, touché.

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

回答by alecxe

There is an another mature and actively developed"player" on the javascript linting front - ESLint:

在 javascript linting 前端还有另一个成熟且积极开发的“播放器” - ESLint：

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. In many ways, it is similar to JSLint and JSHint with a few exceptions:

• ESLint uses Esprima for JavaScript parsing.
• ESLint uses an AST to evaluate patterns in code.
• ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.

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

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

What really matters here is that it is extendable via custom plugins/rules. There are already multiple plugins written for different purposes. Among others, there are:

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

• eslint-plugin-angular(enforces some of the guidelines from John Papa's Angular Style Guide)
• eslint-plugin-jasmine
• eslint-plugin-backbone

• eslint-plugin-angular（强制执行John Papa 的 Angular Style Guide 中的一些指南）
• eslint-plugin-茉莉花
• eslint-plugin-backbone

And, of course, you can use your build tool of choice to run ESLint:

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

• grunt-eslint
• gulp-eslint

• 咕噜咕噜
• 吞咽 - eslint

回答by lexicore

I had the same question a couple of weeks ago and was evaluating both JSLint and JSHint.

几周前我遇到了同样的问题，正在评估 JSLint 和 JSHint。

Contrary to the answers in this question, my conclusion was not:

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

By all means use JSLint.

一定要使用 JSLint。

Or:

或者：

If you're looking for a very high standard for yourself or team, JSLint.

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

As you can configure almostthe same rules in JSHint as in JSLint. So I would argue that there's not much difference in the rules you could achieve.

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

So the reasons to choose one over another are more political than technical.

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

We've finally decided to go with JSHint because of the following reasons:

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

• Seems to be more configurable that JSLint.
• Looks definitely more community-driven rather than one-man-show (no matter how cool The Manis).
• JSHint matched our code style OOTB better that JSLint.

• 似乎比 JSLint 更可配置。
• 看起来肯定更受社区驱动，而不是单人秀（无论The Man有多酷）。
• JSHint 比 JSLint 更符合我们的代码风格 OOTB。

回答by Jeff Foster

I'd make a third suggestion, Google Closure Compiler(and also the Closure Linter). You can try it out online here.

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

The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls.

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

回答by wires

Foreword: Well, that escalated quickly. But decided to pull it through. May this answer be helpful to you and other readers.

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

Code Hinting

代码提示

While JSLint and JSHint are good tools to use, over the years I've come to appreciate what my friend @ugly_syntaxcalls:

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

smaller design space.

更小的设计空间。

This is a general principle, much like a "zen monk", limiting the choices one has to make, one can be more productive and creative.

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

Therefore my current favourite zero-config JS code style:

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

StandardJS.

标准JS。

UPDATE:

更新：

Flowhas improved a lot. With it, you can add types to your JS with will help you prevent a lot of bugs. But it can also stay out of your way, for instance when interfacing untyped JS. Give it a try!

流量改善了很多。有了它，你可以向你的 JS 添加类型，这将帮助你防止很多错误。但它也可以避开你，例如在连接无类型 JS 时。试一试！

Quickstart / TL;DR

快速入门 / TL;DR

Add standardas a dependency to you project

standard作为依赖项添加到您的项目

npm install --save standard

Then in package.json, add the following test script:

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

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

For snazzier output while developing, npm install --global snazzyand run it instead of npm test.

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

Note: Type checking versus Heuristics

注意：类型检查与启发式

My friend when mentioning design space referred to Elmand I encourage you to give that language a try.

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

Why? JS is in fact inspired by LISP, which is a special class of languages, which happens to be untyped. Language such as Elm or Purescriptare typedfunctional programming languages.

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

Type restrict your freedom in order for the compiler to be able to check and guide you when you end up violation the language or your own program's rules; regardless of the size (LOC) of your program.

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

We recently had a junior colleague implement a reactive interface twice: once in Elm, once in React; have a look to get some idea of what I'm talking about.

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

Compare Main.elm(typed) ? index.js(untyped, no tests)

比较Main.elm（输入） ? index.js（无类型，无测试）

(ps. note that the React code is not idiomatic and could be improved)

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

One final remark,

最后一句话，

the reality is that JS isuntyped. Who am I to suggest typed programmingto you?

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

See, with JS we are in a different domain: freed from types, we can easily express things that are hard or impossible to give a proper type (which can certainly be an advantage).

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

But without types there is little to keep our programs in check, so we are forced to introduce tests and (to a lesser extend) code styles.

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

I recommend you look at LISP (e.g. ClojureScript) for inspiration and invest in testing your codes. Read The way of the substackto get an idea.

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

Peace.

和平。

回答by Vikash Pandey

Well, Instead of doing manual lint settings we can include all the lint settings at the top of our JS file itself e.g.

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

Declare all the global var in that file like:

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

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

Declare all the lint settings like:

声明所有 lint 设置，如：

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

Hope this will help you :)

希望能帮到你 ：）

回答by alecxe

There is also an another actively developed alternative - JSCS — JavaScript Code Style:

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

JSCS is a code style linter for programmatically enforcing your style guide. You can configure JSCS for your project in detail using over 150 validation rules, including presets from popular style guides like jQuery, Airbnb, Google, and more.

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

It comes with multiple presetsthat you can choose from by simply specifying the presetin the .jscsrcconfiguration file and customize it - override, enable or disable any rules:

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

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

There are also plugins and extensions built for popular editors.

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

Also see:

另见：

• Perfect code, zero effort

• 完美的代码，零努力