3 番目の等号の使用をやめてはならない理由を 1 つ教えてください。
typeof x === "object"
typeof x == "object" // does the same thing 100% of the time and uses one less character
3 番目の等号の使用をやめてはならない理由を 1 つ教えてください。
typeof x === "object"
typeof x == "object" // does the same thing 100% of the time and uses one less character
1 (非常に) 正当な理由:一貫性。
一般に、できるだけ具体的にする必要があります。可能な限り具体的にする必要があるという一般的なルールに従っている場合は===
、一貫性を保つためにそれを維持する必要があります。さらに、一般的なルールに従うと仮定すると、例外を作成すると、さらに多くの例外が続き、すぐに一般的なルールがなくなります。
1 文字を 100% の確率で入力しなければならない手間よりも、一貫性と特異性を重視します。
この特定の状況では、 の唯一の利点は、===
わずかに高速であることです。
プロファイリングの結果については、http: //jsperf.com/equal-performance (具体的には、「string + double equals」および「string + triple equals」) を参照してください。
オブジェクトタイプを比較していません。文字列を比較します: リテラル ( ) と演算子'object'
によって返された文字列です。typeof
このステートメントでは常に文字列を比較するため、ここで==
or===
を使用しても違いはないと思います。
さて、これまでにほとんどの人が (当然のことながら) 3 つを使用すること=
がベスト プラクティスであると言ってきました。type of value-of
ただし、この例では、比較を使用するときに考えられる落とし穴の 1 つが発生します。たとえば、次のようにします。
var date1 = new Date();
var date2 = new Date(date1.valueOf());
date1
これは、との両方date2
が同じタイプ (オブジェクト、同じオブジェクト: Date) であり、まったく同じ値を持つことを意味します。論理的には:
console.log(date1 === date2);//logs FALSE
なんで?JS オブジェクト変数は参照であるためです。上記のステートメントが実際に行っていることは、メモリ内の 2 つの場所 (両方とも新しいインスタンス) が同じかどうかをチェックすることです。内容はチェックされませんが、メモリアドレスがチェックされます。
したがって、ロジックは次のように指示します。
var date1 = new Date();
var date2 = date1;
console.log(date1 === date2);//True
注: JS は常にその変数の値をコピーしますが、オブジェクトの場合、それらの変数は参照であるため、JS は に格納されているメモリ アドレスをコピーしdate1
ますdate2
。
当然のことながら、2 つの別々のインスタンスのチェックは、二重の等号でも発生する問題です。タイプや値に関係なく、2 つのメモリ アドレスが同じになることはありません。
多くの人が適用していた簡単な修正は、JS オブジェクト プロトタイプのvalueOf
メソッドを上書きすることでした。これはまだ機能しますが、型と値のチェックで問題が発生します (オブジェクト型はまだ役割を果たしています)。
function SomeConstructor()
{
this.foo = 'foobar';
this.bar = function()
{
console.log('I am a messy constructor!');
return this.foo;
};
}
var inst = new SomeConstructor();
inst.valueOf = function()
{
return 1;
}
console.log(inst == 1);//logs true
console.log(inst === 1);//logs FALSE
これを回避するには多くの方法がありますJSON.stringify
。2 つのオブジェクトを処理し、その後それらを解析し、for...in
各プロパティをチェックするために使用している人々を見てきました...必要なことは、valueOf()
戻り値を追加の変数に格納することだけです。 . ジョブ完了(?) 人々が実際に行う必要があるのは、より良いコードを作成することですが、私は疲れていて、トピックから離れてしまいました....目の前の質問に戻ります:
=
では、余分な記号を選択する理由は何かと尋ねる人もいるかもしれません。まあ、一貫性は上で述べたように見えますが、速度はわずかに向上します。
しかし、誰もこの落とし穴について言及していないように見えるのと同様に、誰も安定性について言及していません。
つまり、特にソフト型付け言語でコードを書いているとき、特定の型の特定の数の引数を想定する関数やメソッドを書いていることに気付くということです。
次のステップは、一般にデバッグ中に、関数を次のような行で開始することです。このようargument1 = parseInt(argument1);
なargument1 = argument1 || 0;
コードをすべて一緒に回避することはできませんが、最小限に抑える必要があります。
私自身のことを言えば、関数が型と値のチェックを行っていることがわかった場合、関数を呼び出すときにどのような型の引数が期待されるかをチェックする傾向があります。そうでない場合、関数は、渡すために選択した引数から必要なデータを解析すると仮定します。
基本的に、コードが厳密に見えるほど、使用される可能性が高くなります。
==
- 変数の値をチェックするが、型をチェックしないことを意味します (例: "2" == 2 => true を返します)。
===
- チェック値とそのタイプを意味します (例: "2" === 2 => false を返します。左の引数は文字列で、2 番目の引数は数値であるため、vars は同じではありません)
編集:
===
一般に と同じvar1 == var2 && var1.contructor == var2.contructor
です。
3 番目の等号は、偶数のデータ型を比較します。
JavaScript typeofは文字列を返します。テストされた変数が null の場合のみ、"null" ではなく null が返されます。
typeof xとstringを比較している場合、2 番目の等号は 3 番目など常に同じ値を返します。