私は現在、JavaScriptをJSLintに対して検証し、進歩を遂げています。これは、特にJqueryライブラリーでの作業において、より良いJavaScriptを書くのに役立ちます。
私は今渡って来たJSHint、のフォークJSLint。
だから私は非常にJavaScriptが駆動されたWebアプリケーションのために不思議に思っています。
ここで検証メカニズムを決定し、前進させたいので、これをクライアント側の検証に使用します。
そしてjshintとjslintの違いは？単一のJavaScriptの例で説明してください。
リンク：
回答:
[編集]
この回答は編集されています。以下の元の回答はコンテキストに残しておきます（そうしないと、コメントは意味がありません）。
この質問が最初に行われたとき、JSLintはJavaScriptの主要なリンティングツールでした。JSHintはJSLintの新しいフォークでしたが、まだ元のバージョンからそれほど分岐していませんでした。
それ以来、JSLintはかなり静的なままですが、JSHintは大幅に変更されました。これにより、JSLintのより敵対的なルールの多くが破棄され、新しいルールが大量に追加され、一般に柔軟性が高まりました。また、別のツールESLintが利用可能になりました。これは、さらに柔軟で、より多くのルールオプションがあります。
私の最初の答えでは、JSLintのルールに固執するように強制するべきではないと述べました。警告がスローされた理由を理解していれば、警告を解決するためにコードを変更するかどうかを自分で判断できます。
2011年のJSLintの非常に厳密なルールセットでは、これは合理的なアドバイスでした。JSLintテストに合格できるJavaScriptコードセットはほとんどありません。ただし、今日のJSHintおよびESLintツールで利用できるより実用的なルールにより、警告なしでコードを通過させることは、より現実的な提案です。
それでも、リンターが意図的に行ったことについて不平を言う場合があります。たとえば、常に使用する必要があることはわかって===いますが、今回のみ使用する理由があります==。しかし、それでも、ESLintを使用すると、eslint-disable問題の行の周りを指定するオプションがあるため、警告なしでlintテストに合格でき、残りのコードはルールに従います。（そのようなことをあまり頻繁に行わないでください！）
[元の回答は次のとおりです]
必ずJSLintを使用してください。しかし、結果やそれが警告するすべてのものを修正することにこだわらないでください。これはコードの改善に役立ち、潜在的なバグを見つけるのに役立ちますが、JSLintが不満を言うすべてが実際の問題であるとは限らないので、警告なしでプロセスを完了する必要がないように感じてください。
かなりの長さまたは複雑さを持つほとんどすべてのJavascriptコードは、それがどれほど適切に記述されていても、JSLintで警告を生成します。信じられない場合は、JQueryなどの一般的なライブラリを実行してみてください。
JSLintの警告の中には、他の警告よりも価値のあるものがあります。注意する必要があるのはどれか、重要でないものはどれかを学んでください。すべての警告を検討する必要がありますが、特定の警告をクリアするようにコードを修正する必要はありません。コードを見て、満足していると判断しても問題ありません。JSlintが嫌いなことは、実際には正しいことです。
for (i = 0; i < dontEnumsLength; i++)投げUnexpected '++'ます。その他
tl; dr takeaway：
自分やチームに非常に高い水準を求めているなら、JSLint。しかし、それは必ずしもTHE標準ではなく、単なるA標準です。そのうちのいくつかは、Doug Crockfordという名前のJavaScriptの神から教義的に私たちにもたらされます。もう少し柔軟になりたい場合、またはチームにJSLintの意見を受け入れない古いプロがいる場合、またはJSと他のCファミリ言語を定期的に行き来している場合は、JSHintを試してください。
ロングバージョン：
フォークの背後にある推論は、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 /
だから私はそれがクロックフォード主導ではなく「コミュニティ主導」であるという考えだと思います。実際には、JSHintは、JSLintがスティッカーであるいくつかの文体的でマイナーな構文上の「意見」に対して、一般に少し寛容（または少なくとも構成可能か不可知論的）です。
例として、以下のAとBの両方に問題がないと思われる場合、またはBで利用できないAの1つ以上の側面を持つコードを記述したい場合は、JSHintが適しています。Bが唯一の正しいオプションだと思うなら... 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）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コードを見るのがとても良いと思います。私が同意しない唯一のハード機能は、関数内の複数のvar宣言とforループvar i = 0宣言の憎しみ、および関数宣言の空白の強制のいくつかです。 。
JSLintが強制する空白のいくつかは、必ずしも悪いわけではありませんが、ファミリーの他の言語（C、Java、Pythonなど）のかなり標準的な空白の規則とは同期していません。 Javascriptの規則にも従います。私はこれらのさまざまな言語で1日中執筆しており、コード内でLintスタイルの空白文字を好まないチームメンバーと作業しているため、JSHintはバランスが取れていると思います。それは正当なバグや本当に悪い形であるものを捕まえますが、私が気にしない文体的な意見や構文上の問題のためにJSLintが（時々、私が無効にできない方法で）するように私に吠えません。
多くの優れたライブラリーはLint可能ではありません。これは、JSLintの一部が単に1つのバージョンの「優れたコード」（実際には優れたコード）をプッシュするだけであるという考えに真実があることを私に示しています。しかし、繰り返しになりますが、同じライブラリ（または他の優れたライブラリ）はおそらくヒントになりません。
for (var i = 0; ...; i++)は、ループを自己完結させないためです。スコープiは関数です。構文はブロックスコープを作成しているように見えますが、そうではなく、経験の浅いJavaScriptプログラマーや複数の言語で記述している人々が変数のスコープを誤解し、微妙なバグを引き起こす可能性があります。多くの人（私も含めて）は、すべての宣言を上に配置するのがどのように見えるか気に入らないかもしれませんが、JavaScriptにブロックスコープがないことを思い出させてください。
i誤ってグローバルになることはないという、ビューからの自己完結型です。iブロックスコープではなく関数スコープであるという事実は、変数を最初に宣言する十分な理由ではありません。変数は常に、使用される場所のできるだけ近くで宣言する必要があります（programmers.stackexchange.com/questions/56585/…）。
JavaScriptリンティングフロントには、もう1つの成熟して活発に開発された「プレーヤー」がありESLintます。
ESLintは、ECMAScript / JavaScriptコードにあるパターンを識別してレポートするためのツールです。多くの点で、JSLintおよびJSHintに似ていますが、いくつか例外があります。
- ESLintはJavaScript解析にEsprimaを使用します。
- ESLintはASTを使用してコード内のパターンを評価します。
- ESLintは完全にプラグイン可能で、すべてのルールはプラグインであり、実行時にさらに追加できます。
ここで本当に重要なのは、カスタムプラグイン/ルールを介して拡張可能であることです。さまざまな目的で書かれたプラグインがすでに複数あります。中で他の人、があります。
そしてもちろん、あなたが選んだビルドツールを使って実行することができますESLint：
数週間前に同じ質問があり、JSLintとJSHintの両方を評価していました。
この質問の答えに反して、私の結論はそうではありませんでした：
必ずJSLintを使用してください。
または：
自分やチームに非常に高い水準を求めているなら、JSLint。
JSHintでもJSLintとほぼ同じルールを構成できるためです。したがって、達成できるルールに大きな違いはないと主張します。
したがって、どちらかを選択する理由は、技術的というより政治的です。
次の理由により、JSHintを使用することにしました。
3つ目の提案は、Google Closure Compiler（およびClosure Linter）です。こちらからオンラインでお試しいただけます。
Closure Compilerは、JavaScriptのダウンロードと実行を高速化するためのツールです。これはJavaScriptの真のコンパイラです。ソース言語からマシンコードにコンパイルする代わりに、JavaScriptからより良いJavaScriptにコンパイルします。JavaScriptを解析して分析し、不要なコードを削除して、残っているものを書き換えて最小化します。また、構文、変数参照、および型をチェックし、一般的なJavaScriptの落とし穴について警告します。
序：まあ、それは急速にエスカレートしました。しかし、それを完全に引き継ぐことにしました。この回答があなたや他の読者の役に立つと思います。
JSLintとJSHintは優れたツールですが、長年にわたって、友人の@ugly_syntaxが呼ぶものに感謝するようになりました。
小さなデザインスペース。
これは「禅僧」によく似た一般原則であり、自分がしなければならない選択を制限し、生産性と創造性を高めることができます。
したがって、私のお気に入りのゼロ構成JSコードスタイル：
更新：
フローが大幅に改善されました。それを使用すると、JSにタイプを追加でき、多くのバグを防ぐのに役立ちます。ただし、たとえば、型指定されていないJSとインターフェースする場合など、邪魔にならないようにすることもできます。試してみる！
standardプロジェクトに依存関係として追加する
npm install --save standard次にpackage.json、次のテストスクリプトを追加します。
"scripts": {
"test": "node_modules/.bin/standard && echo put further tests here"
},開発中の出力をすっきりさせ、のnpm install --global snazzy代わりに実行しますnpm test。
私の友人がエルムに言及したデザインスペースに言及するとき、私はその言語を試してみることをお勧めします。
どうして？JSは実際には、たまたま型付けされていない特殊な言語クラスであるLISPに触発されています。ElmやPurescriptなどの言語は、型付き関数型プログラミング言語です。
言語を制限したり、独自のプログラムの規則に違反したりした場合にコンパイラーがチェックおよびガイドできるように、タイプを制限します。プログラムのサイズ（LOC）に関係なく。
最近、後輩に反応型インターフェースを2回実装してもらいました。1回はElmで、1回はReactで、私が何を話しているのかを理解するために見てください。
（ps。Reactコードは慣用的ではなく、改善できる可能性があることに注意してください）
実際には、JS は型付けされていません。型付きプログラミングをあなたに提案するのは誰ですか？
JSを使用すると、別のドメインにいることになります。型から解放されるため、適切な型を与えることが困難または不可能であるものを簡単に表現できます（これは確かに利点になります）。
しかし、型がなければ、プログラムをチェックする必要はほとんどありません。そのため、テストと（より短い範囲で）コードスタイルを導入せざるを得ません。
LISP（ClojureScriptなど）を参考にしてコードをテストすることをお勧めします。アイデアを得るためにサブスタックの方法を読んでください。
平和。
積極的に開発された別の方法もあります-JSCS — JavaScript Code Style：
JSCSは、スタイルガイドをプログラムで適用するためのコードスタイルリンターです。jQuery、Airbnb、Googleなどの人気のあるスタイルガイドのプリセットを含む150以上の検証ルールを使用して、プロジェクトのJSCSを詳細に設定できます。
これには、構成ファイルでを指定してカスタマイズするだけで選択できる複数のプリセットが付属しています-ルールを上書き、有効化、または無効化します。preset.jscsrc
{
"preset": "jquery",
"requireCurlyBraces": null
}人気のあるエディター用にビルドされたプラグインと拡張機能もあります。
こちらもご覧ください：
Combine this with the previous 'var' statement->Do not mix 'require' and other declarations、パラドックス。