我应该使用JSLint或JSHint JavaScript验证吗？ [关闭]

本文翻译自：Should I use JSLint or JSHint JavaScript validation? [closed]

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 . 现在我所遇到JSHint，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: 所以我想知道很多JavaScript驱动的Web应用程序，这是更好或最适用的验证工具：

• 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? 和jshint和jslint之间的区别？ Please explain in single javascript example. 请在单个javascript示例中解释。

Links: 链接：

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

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

---

#1楼

参考：https://stackoom.com/question/SXqj/我应该使用JSLint或JSHint-JavaScript验证吗-关闭

---

#2楼

tl;dr takeaway : tl;博士外卖 ：

If you're looking for a very high standard for yourself or team, JSLint. 如果你正在为自己或团队寻找一个非常高的标准，JSLint。 But its not necessarily THE standard, just A standard, some of which comes to us dogmatically from a javascript god named Doug Crockford. 但它不一定是标准，只是一个标准，其中一些来自于一个名叫Doug Crockford的javascript神的教条。 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的意见，或者定期在JS和其他C系列语言之间来回，请尝试使用JSHint。

long version : 长版 ：

The reasoning behind the fork explains pretty well why JSHint exists: fork后面的原因解释了为什么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/ 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. 所以我想这个想法是它是“社区驱动的”而不是Crockford驱动的。 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. 实际上，JSHint通常对JSLint的一些风格和轻微的语法“意见”更加宽容（或至少可配置或不可知）。

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. 例如，如果您认为下面的A和B都很好，或者如果您想编写具有A中一个或多个B方面的代码，则JSHint适合您。 If you think B is the only correct option... JSLint. 如果你认为B是唯一正确的选择...... JSLint。 I'm sure there are other differences, but this highlights a few. 我确信还有其他差异，但这突出了一些。

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 = 0 declarations , and some of the whitespace enforcements for function declarations. 就个人而言，我发现JSLint代码非常好看，而且我不同意它的唯一硬性特征是它在函数和for-loop var i = 0声明中的多个var声明的仇恨 ，以及一些空白功能声明的强制执行。

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. JSLint强制执行的一些空白内容，我发现不一定是坏的，但是与家庭中其他语言（C，Java，Python等等）的一些非常标准的空白约定不同步，这通常是也遵循Javascript中的约定。 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. 由于我一整天都在用各种语言写作，并且在我们的代码中与不喜欢Lint风格的空白的团队成员合作，我发现JSHint是一个很好的平衡点。 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那样咆哮我（有时候，我无法禁用）对于我不关心的风格观点或句法挑剔。

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). 很多好的库都不是Lint'able，这对我来说证明了一些JSLint只是推送1版“好代码”（这确实是好代码）的想法。 But then again, the same libraries (or other good ones) probably aren't Hint'able either, so, touché. 但话说回来，相同的图书馆（或其他好的图书馆）可能也不是暗示，所以，触摸。

---

#3楼

Well, Instead of doing manual lint settings we can include all the lint settings at the top of our JS file itself eg 好吧，我们可以在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 :) 希望对你有帮助 ：）

---

#4楼

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 almost the same rules in JSHint as in JSLint. 因为您可以在JSHint中配置与JSLint中几乎相同的规则。 So I would argue that there's not much difference in the rules you could achieve. 所以我认为你可以达到的规则没有太大区别。

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. 似乎比JSLint更可配置。
• Looks definitely more community-driven rather than one-man-show (no matter how cool The Man is). 看起来更像是社区驱动而不是单人秀（无论男人有多酷）。
• JSHint matched our code style OOTB better that JSLint. JSHint比JSLint更好地匹配我们的代码样式OOTB。

---

#5楼

There is an another mature and actively developed "player" on the javascript linting front - ESLint : 在javascript ESLint front上有另一个成熟且积极开发的 “播放器” - ESLint ：

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. ESLint是一种用于识别和报告ECMAScript / JavaScript代码中的模式的工具。 In many ways, it is similar to JSLint and JSHint with a few exceptions: 在许多方面，它类似于JSLint和JSHint，但有一些例外：

• ESLint uses Esprima for JavaScript parsing. ESLint使用Esprima进行JavaScript解析。
• ESLint uses an AST to evaluate patterns in code. ESLint使用AST来评估代码中的模式。
• ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime. 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-angular （强制执行John Papa的角度风格指南中的一些指导原则）
• eslint-plugin-jasmine eslint-插件，茉莉
• eslint-plugin-backbone eslint-插件骨干

And, of course, you can use your build tool of choice to run ESLint : 当然，您可以使用您选择的构建工具来运行ESLint ：

• grunt-eslint 咕噜，eslint
• gulp-eslint 一饮而尽，eslint

---

#6楼

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. JSCS是一种代码样式的linter，用于以编程方式强制执行样式指南。 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. 您可以使用超过150个验证规则详细配置项目的JSCS，包括流行样式指南（如jQuery，Airbnb，Google等）的预设。

It comes with multiple presets that you can choose from by simply specifying the preset in the .jscsrc configuration file and customize it - override, enable or disable any rules: 它提供了多个预设 ，您只需在.jscsrc配置文件中指定preset并自定义它即可选择 - 覆盖，启用或禁用任何规则：

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

There are also plugins and extensions built for popular editors. 还有为流行编辑器构建的插件和扩展。

Also see: 另见：

• Perfect code, zero effort 完美的代码，零努力