JSLintは「===」を期待し、代わりに「==」を見ました


90

最近、このエラーが発生したときに、JSLintを介してコードの一部を実行していました。このエラーについて私が面白いと思うのは、すべての==が===であると自動的に想定することです。

それは本当に意味がありますか?タイプを比較したくないインスタンスがたくさん見られましたが、実際に問題が発生するのではないかと心配しています。

「期待される」という言葉は、これが毎回行われるべきであることを意味します.....それは私には意味がありません。


7
私もJSLintでこれに遭遇しました。==から===に更新しましたが、実際には以前に機能していたコードが壊れていました。
kemiller2002 2010

5
コードに100行を超える場合、jslintを渡すことはできません。実際、それは不可能です。

3
「ブローク」という言葉は強すぎる。それはあなたのコードの意味を変えました。あなたがmyVar == nullチェックをしていたら、はい、大きな変化です。; ^)Crockfordの主張は、コードの意味をより正確にしたということであり、それについて議論するのは難しいです。
ラフィン2013年

回答:


127

型変換がどのように機能する===理解しようとせずに、盲目的にを使用するIMOは、あまり意味がありません。

Equals演算子に関する主な懸念==は、比較するタイプに応じた比較ルールによって、演算子が非推移的になる可能性があることです。たとえば、次の場合です。

A == B AND
B == C

それを実際に保証するものではありません:

A == C

例えば:

'0' == 0;   // true
 0  == '';  // true
'0' == '';  // false

===最も一般的な例である同じタイプの値を比較する場合、StrictEquals演算子は実際には必要ありません。

if (typeof foo == "function") {
  //..
}

私たちは、その結果を比較typeof演算子、常に文字列で、文字列リテラルを...

または、たとえば、型強制ルールがわかっている場合は、何かが何かであるnullかどうかを確認しundefinedます。

if (foo == null) {
  // foo is null or undefined
}

// Vs. the following non-sense version:

if (foo === null || typeof foo === "undefined") {
  // foo is null or undefined
}

1
私はJSLintのこのルールが嫌いです。本当の問題は、人々が理解できない方法で演算子を使用してはならないことだと思います(皮肉なことに、これらは「===」を「==」に盲目的に置き換える同じ種類の人々です)。確かに、数値0をさまざまな文字列と比較するときに発生する通常のケースがいくつかありますが、0 == 'これは文字列です'のような無関係なデータを比較している場合-コードにはおそらくdoubleequalよりも大きな問題があります!扱っているタイプが確実にわかっていて、それらが==とどのように相互作用するかを正確に知っている場合は、それを使用する必要があると思います。
ジョン

3
@Jon演算子のポイントは、===コードの明確さです。==恒等演算子ほど明確で理解できるものではないため、使用する合理的な状況はありません。演算子を理解しているかどうかではなく、ほとんど費用をかけずにコードを読みやすくする演算子を使用することです。アイデンティティオペレーターに反対している唯一の開発者は、ソロ開発者とチームで働いていない人々です。定義上、コードを書いている人は十分な目でレビューされていません。
オルタ

2
== nullの比較がほぼ不可欠であることがわかりました。コードが十分にテストされていれば、この問題の重要性はさらに低くなります。
ジョン

1
実際、必要なテストを実行するために、==の使用が不可欠な場合があります。foo.toString()が予測可能な方法で実行され、プレーンな文字列をその出力に対してテストする必要がある場合、foo == stringToTestを記述することは、foo.toString()=== stringToTestよりもはるかにクリーンです。
クリスペンスミス2015

2
@Alternatex要点が明快だった場合、彼らはそれをトリプルイコールにするべきではありませんでした!初心者はそれを理解していません。少なくとも二重等号は他の言語から知られています。また、there is no reasonable situation重大な虚偽表示です。(ネイティブ)JavascriptタイプNumberとについて考えてくださいString。それらの存在は、Javascriptの作者が特定のユースケースを念頭に置いていたことを証明してい==ます。にnew String('hi') === 'hi'評価することfalseは非常に明確だと本当に思いますか?'hi'文字列と文字列の両方を受け入れることに対して関数の引数をテストするコードスニペットを作成し、それが明確であることを教えてください。
Stijn de Witt

25

JSLintは、Javascript構文で許可されているよりも本質的に防御的です。

JSLintのドキュメントから:

==そして!=、オペレータは、比較する前に型の強制を行います。それ' \t\r\n' == 0が真実になるので、これは悪いことです。これにより、タイプエラーをマスクできます。

次の値のいずれかと比較する場合は、===or!==演算子(型強制を行わない)を使用してください。0 '' undefined null false true

値が真実またはであることにのみ関心がある場合は、短い形式を使用してください。の代わりに

(foo != 0)

言うだけ

(foo)

の代わりに

(foo == 0)

いう

(!foo)

===そして!==オペレーターが好ましいです。


8
JSLintの人々は、決して抜け出せない非常に高い象牙の塔で働いていると結論付けなければなりません。Javascriptは、オペレーターで使用するように設計されています==。これ===は特殊なケースです... JSLintは、使用==がどういうわけか間違っているように見せようとします...ただし、これを試してください:var x = 4, y = new Number(4); if (x == y) {alert('Javascript depends on == just embrace it!');}。プリミティブ型には、それらの代わりとなる対応するクラス(NumberString)があり、Javascriptは、==これらを自然に比較するために演算子に依存します。
Stijn de Witt

17

JSLintは、優れたJavaScriptがどうあるべきかという1人の考えを強制することに注意してください。それが示唆する変更を実装するときは、常識を使用する必要があります。

一般に、型と値を比較すると、コードがより安全になります(型変換が想定どおりに機能しない場合でも、予期しない動作が発生することはありません)。


4
さらに、プログラマーのようにコンテキストを賢くすることはできません。ほとんどのユーザーがシステムに固有の自動型変換によってつまずくことに基づいて機能しているだけです(暴力のように-「私が抑圧されているのを助けてください!」)
Rudu 2010

14

Triple-equalはdouble-equalとは異なります。これは、両側が同じ値であるかどうかをチェックするだけでなく、triple-equalもそれらが同じデータ型であることをチェックするためです。

ですから、("4" == 4)は真ですが、("4" === 4)は偽です。

また、JavaScriptは、答えを出す前に型変換を行うのに時間を無駄にする必要がないため、Triple-equalの実行速度もわずかに速くなります。

JSLintは、あいまいなバグを減らすことを目的として、JavaScriptコードを可能な限り厳密にすることを意図的に目的としています。データ型を尊重するように強制する方法でコードを記述しようとするこの種のことを強調しています。

しかし、JSLintの良いところは、それが単なるガイドであるということです。彼らがサイトで言うように、たとえあなたが非常に優れたJavaScriptプログラマーであったとしても、それはあなたの気持ちを傷つけるでしょう。しかし、あなたはそのアドバイスに従う義務を感じるべきではありません。それが言っていることを読んでそれを理解しているが、コードが壊れることはないと確信しているなら、何かを変更するように強制されることはありません。

何もしないという警告が表示されたくない場合は、JSLintにチェックのカテゴリを無視するように指示することもできます。


3
「=== "ってなに?」と聞かなかったので、なぜ答えたのかわかりません。
メトロポリス

8
@Metropolis:他に理由がない場合は、知らない人が答えを読んだ場合の背景として。しかし、私はその後の段落であなたの質問に答えようとしました。
Spudley 2010

追加の有用な情報については@ Spudley + 1
ベンジュニア


8

http://javascript.crockford.com/code.htmlからの引用:

===および!==演算子。

ほとんどの場合、===および!==演算子を使用することをお勧めします。==および!=演算子は、型強制を行います。特に、偽の値と比較するために==を使用しないでください。

JSLintは非常に厳密であり、「webjslint.js」は独自の検証に合格していません。


良い説明。それは本当です、webjslint.js検証しないことについて-私が今見ているエラーのほとんどは間隔に関係していますが。明らかに、JSLintを使用してJavaScriptをレビューするときは、常識と合理的な判断を使用する必要があります。
hotshot309 2011

この言葉を使用すると、alwaysこの引用は自動的に知恵として失格になります。スマートプログラマーは独断的ではありません。彼らは与えられた状況で最良のものを使用します。そして、彼らは言語の核心に組み込まれているツールを歓迎し、受け入れますjust never touch it。単に。でそれを却下するだけではありません。=結論:私のコードは(1文字を保存するだけでなく)短くなるため、サイトの読み込みが速くなり、帯域幅のコストが少なくなり、ユーザーへのサービスが向上します。
Stijn de Witt

4

偽りをテストしたい場合。JSLintは許可しません

if (foo == null)

しかし、許可します

if (!foo)

===JSLintが推奨するを使用します。
クリックベイト2015年

1
@NarawaGamesこのソリューションは完全に受け入れられます。

この答えは良くありません。問題は、これらの両方が何か他のものを意味するということです。foo == nullnullまたは未定義をチェックします。!foonull、未定義、0、および空の文字列をチェックします。
マルコス2016年

@Markosこの回答は、JSLintを満足させ、コードロジックをそのまま維持するための有用な代替手段であり、完全に同等ではありません。これが、回答の前に「偽りをチェックする場合」を付けた理由です
nano2nd

3

この質問を説明し、NetBeans(from)7.3がこの警告を表示し始めた理由を説明するために、これは誰かがこれをバグとして報告したときのNetBeansバグトラッカーの応答からの抜粋です。

JavaScriptでは==ではなく===を使用することをお勧めします。

==演算子と!=演算子は、比較する前に型強制を行います。'\ t \ r \ n' == 0が真になるので、これは悪いことです。これにより、タイプエラーをマスクできます。JSLintは、==が正しく使用されているかどうかを確実に判断できないため、==および!=をまったく使用せず、代わりに、より信頼性の高い===および!==演算子を常に使用することをお勧めします。

参照


1
Netbeansを使用しているときに、このエラーが見つかりました。彼らが提供した奇妙な例のケースのために、彼らがこれを警告の重大​​度で扱うのは奇妙です。
omikes 2017

1
つまり、本当ですが、比較した2つのものが同じタイプになることを人が知っているユースケースが多いので、この奇妙なケースのために、キャリッジリターンが数と比較される可能性があるのは奇妙に思えますゼロは、==のすべての使用法が間違っていると見なされる理由です。型変換が行われないので、===の方が速いのですが。私はnetbeansの前にこれを見つけられなかったことに驚いています。
omikes 2017

@oMiKeYはい、私はあなたが何を意味するのかわかります、彼らはもっと現実的な例を与えることができたでしょう!
EM-Creations

2

まあ、それは本当に問題を引き起こすことはできません、それはあなたにアドバイスを与えるだけです。それを取るか、それを残す。とはいえ、それがどれほど賢いかはわかりません。それが問題として提示されない状況があるかもしれません。


しかし、なぜ「期待される」という言葉が使われるのでしょうか。それはあなたがいつもこれをしなければならないように聞こえます。
メトロポリス

4
評価者は、検証しようとしているため、有効な応答を探しています。有効な応答が得られない場合は、期待したものではありません。バリデーターは、すべてが正常であるという仮定から始まり、コードをトラバースするときにエラーを指摘します。無効な応答が何であるかを必ずしも理解しているわけではなく、無効な応答をいつ検出したかを知っているだけです。また、逆に機能して、何が悪いのかというルールに従って意図的に悪いコードを検索することもできます。ホワイトリストとブラックリスト。
Rushyo 2010

質問は「それは本当に意味がありますか?」でした。その質問を考えると、はい、そうです。また、5年前のことです。イエス。
Rushyo 2016年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.