JSLint Oczekiwano „===”, a zamiast tego zobaczył „==”

Ostatnio uruchamiałem część mojego kodu przez JSLint, kiedy wpadłem na ten błąd. Uważam jednak, że zabawne w tym błędzie jest to, że automatycznie zakłada, że ​​all == powinno być ===.

Czy to naprawdę ma sens? Widziałem wiele przypadków, w których nie chciałbyś porównywać typów i obawiam się, że może to faktycznie powodować problemy.

Słowo „Oczekiwany” sugerowałoby, że powinno się to robić KAŻDY raz ..... To nie ma dla mnie sensu.

IMO, używanie na ślepo ===, bez próby zrozumienia, jak działa konwersja typów , nie ma większego sensu.

Główna obawa związana z operatorem Equals ==polega na tym, że reguły porównania w zależności od porównywanych typów mogą sprawić, że operator będzie nieprzechodni, na przykład, jeśli:

A == B AND
B == C

Naprawdę nie gwarantuje, że:

A == C

Na przykład:

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

Operator Strict Equals ===nie jest konieczny, gdy porównujesz wartości tego samego typu, najczęstszy przykład:

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

Porównujemy wynik typeofoperatora, który zawsze jest ciągiem , z literałem ciągu ...

Lub kiedy znasz reguły wymuszania typów, na przykład sprawdź, czy coś jest, nullczy undefinedcoś:

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
}

JSLint jest z natury bardziej defensywny, niż pozwala na to składnia JavaScript.

Z dokumentacji JSLint:

==I !=operatorzy zrobić rodzaj przymusu przed porównaniem. To jest złe, ponieważ powoduje, ' \t\r\n' == 0że jest prawdą. Może to maskować błędy typu.

Porównując z dowolną z poniższych wartości, użyj operatorów ===lub !==(które nie powodują wymuszenia):0 '' undefined null false true

Jeśli zależy Ci tylko na tym, aby wartość była prawdziwa lub fałszywa , użyj krótkiej formy. Zamiast

(foo != 0)

tylko powiedz

(foo)

i zamiast

(foo == 0)

mówić

(!foo)

===I !==preferowane są operatorzy.

Pamiętaj, że JSLint narzuca jednej osobie wyobrażenie o tym, jaki powinien być dobry JavaScript. Nadal musisz kierować się zdrowym rozsądkiem przy wdrażaniu sugerowanych zmian.

Ogólnie rzecz biorąc, porównanie typu i wartości uczyni twój kod bezpieczniejszym (nie napotkasz nieoczekiwanego zachowania, gdy konwersja typów nie zrobi tego, co myślisz, że powinna).

Potrójne równe różni się od podwójnie równe, ponieważ oprócz sprawdzenia, czy dwie strony mają tę samą wartość, potrójnie równe sprawdza również, czy są one tego samego typu danych.

Tak ("4" == 4)jest prawdą, podczas gdy ("4" === 4)jest fałszem.

Potrójne równe również działa nieco szybciej, ponieważ JavaScript nie musi tracić czasu na wykonywanie jakichkolwiek konwersji typów przed udzieleniem odpowiedzi.

JSLint celowo ma na celu uczynienie kodu JavaScript tak ścisłym, jak to tylko możliwe, w celu zmniejszenia liczby niejasnych błędów. Podkreśla tego rodzaju rzeczy, próbując nakłonić cię do kodowania w sposób, który zmusza cię do poszanowania typów danych.

Ale dobrą rzeczą w JSLint jest to, że jest to tylko przewodnik. Jak mówią na stronie, to zrani twoje uczucia, nawet jeśli jesteś bardzo dobrym programistą JavaScript. Ale nie powinieneś czuć się zobowiązany do przestrzegania jego rad. Jeśli przeczytałeś, co ma do powiedzenia i rozumiesz to, ale masz pewność, że Twój kod się nie zepsuje, nie ma na tobie żadnego przymusu, aby cokolwiek zmienić.

Możesz nawet powiedzieć JSLint, aby ignorował kategorie kontroli, jeśli nie chcesz być bombardowany ostrzeżeniami, z którymi nie zamierzasz nic robić.

Cytat z http://javascript.crockford.com/code.html :

=== i! == Operatory.

Prawie zawsze lepiej jest używać operatorów === i! ==. Operatory == i! = Wymuszają wpisywanie. W szczególności nie używaj == do porównywania z fałszywymi wartościami.

JSLint jest bardzo rygorystyczny, ich „webjslint.js” nie przechodzi nawet własnej weryfikacji.

Jeśli chcesz przetestować pod kątem fałszywości. JSLint nie pozwala

if (foo == null)

ale pozwala

if (!foo)

Aby pomóc wyjaśnić to pytanie, a także wyjaśnić, dlaczego NetBeans (from) 7.3 zaczął wyświetlać to ostrzeżenie, jest to wyciąg z odpowiedzi w narzędziu do śledzenia błędów NetBeans, gdy ktoś zgłosił to jako błąd:

Dobrą praktyką jest używanie === zamiast == w JavaScript.

Operatory == i! = Wymuszają wpisywanie przed porównaniem. To jest złe, ponieważ powoduje, że '\ t \ r \ n' == 0 jest prawdziwe. Może to maskować błędy typu. JSLint nie może wiarygodnie określić, czy == jest używane poprawnie, więc najlepiej w ogóle nie używać == i! = I zamiast tego zawsze używać bardziej niezawodnych operatorów === i! ==.

Odniesienie

Cóż, tak naprawdę nie może powodować problemów, po prostu daje rady. Zdecyduj sie. To powiedziawszy, nie jestem pewien, jakie to sprytne. Mogą istnieć konteksty, w których nie przedstawia tego jako problemu.