boolean w instrukcji if

Dzisiaj dostałem uwagę na temat kodu, biorąc pod uwagę sposób, w jaki sprawdzam, czy zmienna jest prawdziwa, czy fałszywa w zadaniu szkolnym.

Kod, który napisałem, wyglądał mniej więcej tak:

var booleanValue = true;

function someFunction(){
    if(booleanValue === true){
        return "something";
    }
}

Powiedzieli, że lepiej / schludniej napisać to w ten sposób:

var booleanValue = true;

function someFunction(){
    if(booleanValue){
        return "something";
    }
}

Uwaga, którą otrzymałem na temat części „=== prawda” była taka, że ​​nie jest ona potrzebna i może powodować zamieszanie.

Jednak moim pomysłem jest to, że lepiej jest sprawdzić, czy zmienna jest logiczna, czy nie, zwłaszcza, że ​​JavaScript jest językiem o luźnym typie.

W drugim przykładzie łańcuch również zwróciłby „coś”;

Więc moje pytanie; Czy w przyszłości lepiej jest stracić część „=== true”, czy też dobrą praktyką jest sprawdzenie również typu zmiennej.

Edycja: W moim „prawdziwym” kodzie wartość logiczna reprezentuje, czy obraz został usunięty, czy nie, więc jedyne wartości, które powinna mieć wartość boolValue, to true lub false.

Na przykład 0 i 1 nie powinny znajdować się w tej zmiennej.

Po pierwsze, fakty:

if (booleanValue)

Zaspokoi ifoświadczenie o dowolnej wartości truthy z booleanValuetym true, każda niezerowa liczba, każdy niepusty ciąg znaków, dowolny obiekt lub tablica referencyjna, itd ...

Z drugiej strony:

if (booleanValue === true)

Spowoduje to spełnienie ifwarunku tylko wtedy, gdy booleanValuejest dokładnie równe true. Żadna inna prawdziwa wartość tego nie zadowoli.

Z drugiej strony, jeśli to zrobisz:

if (someVar == true)

Następnie JavaScript wykona wpisanie przymusu, trueaby dopasować typ, someVara następnie porównać dwie zmienne. Jest wiele sytuacji, w których prawdopodobnie nie jest to zamierzone. Z tego powodu w większości przypadków chcesz tego uniknąć, ==ponieważ istnieje dość długi zestaw reguł dotyczących tego, w jaki sposób JavaScript wymusza dwie rzeczy, aby były tego samego typu, chyba że rozumiesz wszystkie te zasady i możesz przewidzieć wszystko, co interpreter JS może zrobić, gdy biorąc pod uwagę dwa różne typy (których większość programistów JS nie potrafi), prawdopodobnie chcesz ==całkowicie uniknąć .

Jako przykład tego, jak zagmatwany może być:

var x;

x = 0;
console.log(x == true);   // false, as expected
console.log(x == false);  // true as expected

x = 1;
console.log(x == true);   // true, as expected
console.log(x == false);  // false as expected

x = 2;
console.log(x == true);   // false, ??
console.log(x == false);  // false 

Jeśli chodzi o wartość 2, można by pomyśleć, że 2jest to prawdziwa wartość, więc można by ją porównać korzystnie true, ale nie tak działa wymuszanie typu. Konwertuje wartość prawej ręki, aby dopasować typ wartości lewej ręki, więc konwertuje trueją na liczbę, 1więc porównuje, 2 == 1co z pewnością nie jest tym, co prawdopodobnie zamierzałeś.

Więc strzeż się kupującego. Prawdopodobnie najlepiej jest tego unikać ==w prawie wszystkich przypadkach, chyba że dokładnie znasz typy, które będziesz porównywać, i wiesz, jak działają wszystkie możliwe algorytmy wymuszania typów.

Tak więc naprawdę zależy to od oczekiwanych wartości booleanValuei sposobu działania kodu. Jeśli wiesz z góry, że będzie miał tylko wartość a truelub false, porównaj ją jawnie z

if (booleanValue === true)

to tylko dodatkowy kod i niepotrzebne i

if (booleanValue)

jest bardziej kompaktowy i prawdopodobnie czystszy / lepszy.

Jeśli z drugiej strony nie wiesz, co booleanValuemoże być i chcesz sprawdzić, czy jest naprawdę ustawiona na truebez innych automatycznych konwersji typów, to

if (booleanValue === true)

to nie tylko dobry pomysł, ale wymagany.

Na przykład, jeśli spojrzysz na implementację .on()w jQuery, ma ona opcjonalną wartość zwracaną. Jeśli wywołanie zwrotne powróci false, jQuery automatycznie zatrzyma propagację zdarzenia. W tym konkretnym przypadku, ponieważ jQuery chce propagacji zatrzymują się tylko jeśli falsezostał zwrócony, sprawdzić ich wartość zwracana explicity za === falsebo nie chcą undefinedlub 0lub ""lub cokolwiek innego, co spowoduje automatyczne typu nawróconego false aby również spełniać porównanie.

Na przykład, oto kod wywołania zwrotnego obsługi zdarzenia jQuery:

ret = ( specialHandle || handleObj.handler ).apply( matched.elem, args );

if ( ret !== undefined ) {
     event.result = ret;
     if ( ret === false ) {
         event.preventDefault();
         event.stopPropagation();
     }
 }

Widać, że jQuery wprost szuka ret === false.

Ale jest też wiele innych miejsc w kodzie jQuery, w których prostsze sprawdzenie jest właściwe, biorąc pod uwagę pożądany kod. Na przykład:

// The DOM ready check for Internet Explorer
function doScrollCheck() {
    if ( jQuery.isReady ) {
        return;
    }
    ...

Jeśli napiszesz if(x === true):, Będzie to prawda tylko dla x = prawda

Jeśli napiszesz if(x):, będzie prawdziwe dla każdego x, które nie jest: '' (pusty łańcuch), false, null, undefined, 0, NaN.

W zwykłym "if" zmienna zostanie przekształcona na wartość logiczną i używa toBoolean na obiekcie: -

    Argument Type   Result

    Undefined       false
    Null            false
    Boolean         The result equals the input argument (no conversion).
    Number          The result is false if the argument is +0, −0, or NaN;
                    otherwise the result is true.
    String          The result is false if the argument is the empty 
                    String (its length is zero); otherwise the result is true.
    Object          true.

Ale porównanie z === nie ma żadnego typu przymusu, więc muszą być równe bez przymusu.

Jeśli mówisz, że obiekt może nawet nie być wartością logiczną, być może będziesz musiał rozważyć więcej niż tylko prawda / fałsz.

if(x===true){
...
} else if(x===false){
....
} else {
....
}

To zależy od twojego przypadku. Może być sensowne sprawdzenie typu, ale jeśli jest to tylko flaga, tak nie jest.

Ogólnie rzecz biorąc, łatwiej jest pominąć rozszerzenie === true.

Jednak w Javascript te stwierdzenia są inne.

if (booleanValue)wykona jeśli booleanValuejest truthy - coś innego niż 0, false, '', NaN, null, i undefined.

if (booleanValue === true)wykona tylko wtedy, gdy booleanValuejest dokładnie równe true.

(===)Operator tożsamości zachowuje się identycznie jak (==)operator równości , z wyjątkiem tego, że nie jest wykonywana żadna konwersja typów, a typy muszą być takie same, aby były uznawane za równe.

Ponieważ zaznaczona wartość jest Booleanpreferowana, zaleca się użycie jej bezpośrednio w celu zmniejszenia kodowania iw ogóle zrobiło to samo==true

Ponieważ już zainicjowałeś wyraźnie jako bool, myślę, że ===operator nie jest wymagany.

Jeśli zmienna może zawsze przyjmować tylko wartości logiczne, rozsądne jest użycie krótszej składni.

Jeśli może potencjalnie być przypisane inne typy, a trzeba odróżnić trueod 1lub "foo", następnie należy użyć === true.

Myślę, że twoje rozumowanie jest rozsądne. Jednak w praktyce stwierdziłem, że znacznie częściej pomija się ===porównanie. Myślę, że są ku temu trzy powody:

1. Zwykle nie dodaje to znaczenia wyrażeniu - tak jest w przypadkach, gdy wiadomo, że wartość jest logiczna.
2. Ponieważ w JavaScript występuje duża niepewność typu, wymuszenie sprawdzenia typu zwykle gryzie Cię, gdy pojawia się nieoczekiwana wartość undefinedlub nullwartość. Często chcesz po prostu, aby test zakończył się niepowodzeniem w takich przypadkach. (Chociaż staram się zrównoważyć ten pogląd hasłem „szybko przegrywaj”).
3. Programiści JavaScript lubią szybko bawić się typami - szczególnie w wyrażeniach boolowskich - ponieważ możemy.

Rozważmy ten przykład:

var someString = getInput();
var normalized = someString && trim(someString);  
// trim() removes leading and trailing whitespace

if (normalized) {
    submitInput(normalized);
}

Myślę, że tego rodzaju kod nie jest rzadkością. Zajmuje się przypadki, w których getInput()powraca undefined, nulllub pusty ciąg. Ze względu na dwie wartości logiczne submitInput()jest wywoływana tylko wtedy, gdy dane wejście jest łańcuchem zawierającym znaki inne niż białe znaki.

W JavaScript &&zwraca swój pierwszy argument, jeśli jest fałszywy, lub drugi argument, jeśli pierwszy argument jest prawdziwy; tak normalizedbędzie, undefinedjeśli someStringbyło nieokreślone i tak dalej. Oznacza to, że żadne dane wejściowe do powyższych wyrażeń logicznych nie są w rzeczywistości wartościami logicznymi.

Wiem, że wielu programistów, którzy są przyzwyczajeni do silnego sprawdzania typów, wzdraga się, widząc taki kod. Ale uwaga, stosowanie silnego pisania prawdopodobnie wymagałoby jawnych sprawdzeń dla nulllub undefinedwartości, co zagraciłoby kod. W JavaScript nie jest to potrzebne.

To zależy. Jeśli obawiasz się, że twoja zmienna może skończyć się jako coś, co zostanie rozwiązane jako PRAWDA. Wtedy twarde sprawdzenie jest koniecznością. W przeciwnym razie to zależy od Ciebie. Jednak wątpię, czy składnia whatever == TRUEkiedykolwiek zmyliłaby każdego, kto wiedział, co robią.

W Javascript idea boolean jest dość niejednoznaczna. Rozważ to:

 var bool = 0 
 if(bool){..} //evaluates to false

 if(//uninitialized var) //evaluates to false

Więc kiedy używasz instrukcji if (lub jakiejkolwiek innej instrukcji sterującej), nie musisz używać zmiennej typu „boolean”. Dlatego moim zdaniem część "=== prawda" twojego stwierdzenia jest niepotrzebna, jeśli wiesz, że jest to wartość logiczna, ale jest absolutnie konieczna, jeśli twoja wartość jest niejednoznaczną zmienną "prawdziwą". Więcej na temat wartości logicznych w javscript można znaleźć tutaj .

Revisa https://www.w3schools.com/js/js_comparisons.asp

przykład:

var p=5;

p==5 ? true
p=="5" ?  true
p==="5" ? false

=== oznacza ten sam typ i tę samą wartość == tę samą wartość

Można również przetestować za pomocą obiektu Boolean, jeśli chcesz przetestować obiekt error={Boolean(errors.email)}