Nadużywanie operatora ===?

Co myślicie o modzie, że teraz wszędzie gdzie można pcha się === i !==. Temat zastanawia mnie od dłuższego czasu i wraca co code review. I jak widzę taki przykład

dispatch(setExportTableEnabled(responseJson.status === 200))

to jest mi słabo. Nie uważacie że powinno się używać operatora domyślnego i krótszego ==? W PHP jakoś == jest częściej używany

assembler napisał(a):

I jak widzę taki przykład

dispatch(setExportTableEnabled(responseJson.status === 200))

to jest mi słabo.

Czemu jest Ci słabo?

Nie uważacie że powinno się używać operatora domyślnego i krótszego ==?

Nie

Ja tam jestem za tym, żeby było więcej równości.
Im więcej równości tym lepiej.
===============================================

po co używać dwóch? można się pomylić, nie lepiej wszędzie używać ===.

Gdzie === sprawdza dodatkowo typ danych

Podstawowe pytanie - w czym to przeszkadza? Możesz jakoś uzasadnić, co w tym złego? Bo ja uważam (podobnie do @phanc powyżej) - taki zapis sprawdza nie tylko wartość, ale typ, więc robi to samo co wersja krótsza, ale jeszcze ma bonus.

No chyba, że ktoś chce porównać wartości, ale nie patrząc na typ - tylko wtedy to nie jest kwestia preferencji, ale odpowiedniego doboru do potrzeb, więc także nie zalicza się to do tematyki tego wątku. W każdym razie - nie widzę niczego złego w zastosowaniu operatora identyczny zamiast równy.

A mi słabo, jak widzę mały projekt w reactcie i nawalone reduxy i customowy hooksy do niego.

Kogoś jeszcze coś słabi?

jarekr000000 napisał(a):

Ja tam jestem za tym, żeby było więcej równości.

Im więcej równości tym lepiej.
===============================================

To całkiem dobry pomysł. Żeby jeszcze każdy znak równości odpowiadał polu obiektu, byłoby to fajne sprawdzanie całego drzewa. Powiedzmy, że mamy kod

class Point {
	int x, y;
public:
	Point(): x(0), y(0) {}
};
//---
	auto p1 = Point();
	auto p2 = Point();

	if (p1 ==== p2) {
		cout << "dupa" << endl;
	}

Niech będzie to == jako porównanie referencji plus dodatkowy znak dla każdego kolejnego pola w klasie. Pójdźmy krok dalej i napiszmy kolejną klasę!

class Rectangle {
	Point corners[4];
public:
	Rectangle() = default;
};
//----

	auto r1 = Rectangle();
	auto r2 = Rectangle();

	if (r1 ============== r2) {
		cout << "dupa" << endl;
	}

Mamy tu dwa standardowe znaki równości + 4 * (referencja + 2 pola). Razem 14 :) .

urke napisał(a):

Kogoś jeszcze coś słabi?

Standardowo. Metody zaczynające się od wielkiej litery i ludzie którzy nie wiedzą że istnieje polimorfizm poza językami OOP

PerlMonk napisał(a):

Kopiuj

	if (r1 ============== r2) {
		cout << "dupa" << endl;
	}

To mi się podoba. Nie dość, że podkreśla równość między r1 i r2 (zdodnie z hasłem: wszystkie rn są równe) to jeszcze zgodne z zasadami dystansu społecznego, ogranicza przenoszenie się zarazków.

Stosuje się w zależności od potrzeby więc co ci takiego w tym nie tak? to tak jakbyś narzekał, że ktoś czasem da if else czasem ? x : y a czasem ?: y

Aha i w php tez już się zaczyna coraz bardziej to stosować bo tez wchodzi coraz bardziej porządne typowanie.

Nie wiem jak to działa w php ale w js/ts dobrą praktyką jest używanie === bo mało kto rozumie jak działa == co powodowało wiele błędów.
Np dla mnie poniższe odpowiedzi są mało intuicyjne i w gąszczu kodu wątpię abym wyłapał szybko tego typu błędy.

null == undefined //true
[0] == false //true
[1] == 1 //true
[[]] == "" //true

assembler napisał(a):

Nie uważacie że powinno się używać operatora domyślnego i krótszego ==?

Ja jestem zwolennikiem mocnych typów danych i uważam, że === jest domyślny.

Ja bym chciał, żeby typy były domyślnie sprawdzane z ==, a żeby miękkie sprawdzanie miało jakiś trudniejszy do zapisania operator. Miękkie typowanie doprowadza do baaaardzo wielu trudnych do wychwycenia błędów, szczególnie 0 == ''.

Dla przypomnienia javascript equality table:

fajne rzeczy z tego widać :-)

[0] == false
true
[0] == [0]
false

Logiczne

Dla porównania - w mniej zaawansowanych językach:

tu źródło

(I tu warto zaznaczyć, że to że [] == "" w Haskellu jest uznawane za błąd w designie języka, który niestety trudno teraz odkręcić)

=== nie tylko stwarza mniej problemów (zwłaszcza gdy porównujemy tablice, undefined, zero, boolean itp) ale też jest szybsze. Jeśli nie chcemy porównywać zmiennych o różnych typach, dane nie przychodzą od usera i nie chcemy niespodziankowego rzutowania typów to lepiej użyć ===

https://jsbench.me/wskgl15rpr/1

Słabe to jest to, że zarówno do podstawiania jak i porównywania używa się znaków równości, a na dodatek parser JS nie widzi żadnego problemu w takim zapisie:

var x=1;
if (x=2) alert(2);

Bo przecież każdy normalny człowiek będzie zainteresowany sprawdzeniem tego, czy operacja podstawienia się udała :p

Nie wiem, jak innym, ale mi się raz na jakiś czas zdarza taki błąd i szukanie go zawsze rozwija poziom kwiecistości mego języka.

Słabe to jest to, że zarówno do podstawiania jak i porównywania używa się znaków równości

I tutaj wbija na białym, bardzo leciwym (jakieś 50 lat) koniu Pascal ze swoim = sprawdzenie oraz := przypisanie. Ciężko to pomylić :P

cerrato napisał(a):

Słabe to jest to, że zarówno do podstawiania jak i porównywania używa się znaków równości

I tutaj wbija na białym, bardzo leciwym (jakieś 50 lat) koniu Pascal ze swoim = sprawdzenie oraz := przypisanie. Ciężko to pomylić :P

No fajnie, ale tu też możesz zapomnieć jednego znaku i kod się skompiluje. Co za różnica czy to jest dwukropek czy drugi znak równości?

Tak, ale ten brak dwukropka od razu widać gołym okiem. Jak masz same równasię w ilości 1 do 3, to potem można się zakręcić. A ten dwukropek jest tak wyróżniający, że uwierz mi - po jakimś czasie od razu się jego brak rzuca w oczy. Przez wieeeele lat pisania w Pascalu nie przypominam sobie ani razu sytuacji, w której zastosowałem zamiennie = lub :=. Nie umiem tego wyjaśnić, ale takie podejście od samego początku, że jak chcesz przypisać to dodajesz dwukropek wyrabia pewne nawyki, które potem się przekładają na automatyczne pisanie. Coś jak w przypadku kierowcy, który po jakimś czasie w ogóle nie myśli o zmianie biegów, to się dzieje samodzielnie.

Może @furious programming będzie miał coś ciekawego do dodania ;)

@cerrato: Przyzwyczajenie - równie dobrze mogę się przyzwyczaić do odwracania kolejności operandów. Tu mówisz o dwóch różnych rzeczach: zabezpieczeniu na poziomie języka i człowieka. Gdybym chciał zrobić to na poziomie języka, zrobiłbym to tak cmp (zmienna, dupa) i nie stosował znaku równości do porównania.

cerrato napisał(a):

Słabe to jest to, że zarówno do podstawiania jak i porównywania używa się znaków równości

I tutaj wbija na białym, bardzo leciwym (jakieś 50 lat) koniu Pascal ze swoim = sprawdzenie oraz := przypisanie. Ciężko to pomylić :P

:= jest już lepsze, ale jak wchodziłam w Pascal z Basica, to też mi się myliło.
To powinno być raczej coś zupełnie odmiennego, coś w stylu:
x << a + b

Freja Draco napisał(a):

To powinno być raczej coś zupełnie odmiennego, coś w stylu:
x << a + b

Rozwiązanie twoich problemów jest przypisanie nie zwracające wartości co często jest robione w nowszych językach programowania. Np. w Scali if (a = b) jest niepoprawne bo a = b zwraca Unit. Podobnie w Ruscie jest w dokumentacji

let x = (y = 6);  // x has the value `()`, not `6`

Freja Draco napisał(a):

:= jest już lepsze, ale jak wchodziłam w Pascal z Basica, to też mi się myliło.
To powinno być raczej coś zupełnie odmiennego, coś w stylu:
x << a + b

Ew. rozwiązaniem mogłoby być też podejście zupełnie odmienne:
x = 1 + 2;
if (x = 2) wystrzel_rakietę();
I parser, który zależnie od kontekstu odpowiednio interpretuje znak równości.
Chociaż możliwe, że to też mogłoby czasem generować jakieś nieoczywiste błędy.

Freja Draco napisał(a):

Ew. rozwiązaniem mogłoby być też podejście zupełnie odmienne:
x = 1 + 2;
if (x = 2) wystrzel_rakietę();
I parser, który zależnie od kontekstu odpowiednio interpretuje znak równości.
Chociaż możliwe, że to też mogłoby czasem generować jakieś nieoczywiste błędy.

Jeśli przypisanie zwraca zawsze unit/void, a porównanie zwraca zawsze boolean to nie powinno być to problemem. (Dalej problemem jest to że JS jest dynamicznie typowany) Tak jest przecież SQLu. Tak było w pascalopodobnym języku programowania w GameMakerze jak się tym bawiłem 10 lat temu

PerlMonk napisał(a):

No fajnie, ale tu też możesz zapomnieć jednego znaku i kod się skompiluje.

What?! Panie, kod w żadnym dialekcie Pascala nigdy nie zostanie skompilowany, jeśli zamiast operatora przypisania użyjesz porównania. Czemu takie fake newsy rozpuszczasz? :P

cerrato napisał(a):

Tak, ale ten brak dwukropka od razu widać gołym okiem. Jak masz same równasię w ilości 1 do 3, to potem można się zakręcić.

Myślę, że po jakimś czasie da się tego nauczyć i wstawiać te operatory odruchowo. Co w dalszym ciągu nie zmienia faktu, że trzy różne operatory porównania to trzy razy więcej miejsc do popełnienia błędów. I za to twórcy języka „powinni zapier****ć na galerze”.

A ten dwukropek jest tak wyróżniający, że uwierz mi - po jakimś czasie od razu się jego brak rzuca w oczy.

Rzuca się w oczy, a jeszcze bardziej błędy kompilacji wynikające z jego braku. ;)

Przez wieeeele lat pisania w Pascalu nie przypominam sobie ani razu sytuacji, w której zastosowałem zamiennie = lub :=.

A mi się zdarzało wielokrotnie — czasem się nie wpisał, bo albo za szybko pisałem i myślałem o dalszej części, albo źle stuknąłem w klawisz. No ale taka konstrukcja nie ma prawa się skompilować, bo rezultat każdego porównania musi być do czegoś użyty — przypisany do zmiennej lub puszczony jako argument funkcji.

To samo w drugą stronę — przypisanie jest możliwe tylko do zmiennej i nie ma możliwości wykorzystania go np. w nagłówku instrukcji warunkowej czy w wywołaniu funkcji (w argumencie). Pascal nie posiada patologii znanej z C, i bardzo dobrze, bo dzięki temu jest banalny do zrozumienia.

assembler napisał(a):

Nie uważacie że powinno się używać operatora domyślnego i krótszego ==?

Czemu konkretnie == miałby być "domyślny"?

W PHP jakoś == jest częściej używany

Nie jest.

TomRiddle napisał(a):

Nie jest.

Skąd wiesz?

PerlMonk napisał(a):

TomRiddle napisał(a):

Nie jest.

Skąd wiesz?

Sam piszę często w PHP prywatnie (libka) i w pracy (nie mam wyboru), i nie mam ani jednego == w projekcie.

I całe szczęście, bo '1000' == '10e3'.

jarekr000000 napisał(a):

Ja tam jestem za tym, żeby było więcej równości.

Im więcej równości tym lepiej.
===============================================

Chciałbym zwrócić uwagę, że ten przykład jest nierówny. Występuje 47 znaków równości czyli nieparzyste. Aby była klasyczna równość pasowałoby mieć jednak parzystą ilość równości.

@TomRiddle: nie tłumacz im. Oni wiedzą lepiej jak wygląda praca w PHP, bo przecież te 10 lat temu fajnie było się pośmiać :)