Czy używacie jawnego porównania do `== true` w warunkach?

Czy uzywacie zapisu: if (variableName == true) lub if (variableName == false)? Dla mnie wyglada to dziwnie, malo czytelnie i ja od zawsze uzywam zapisu if (variableName) lub if (!variableName), ale niektóre osoby z teamu używają tego czasami, bo "to jest bardziej czytelne".

Nigdy ale czasem w Scali zdarza mi się

variableName match {
  case true  => doSomethingIfTrue
  case false => doSomethingIfFalse
}

No bo w Haskellu:

doSomething :: Bool -> Result
doSomething True  = doSomethingIfTrue
doSomething False = doSomethingIfFalse

Jest raczej normalne

niektóre osoby z teamu używają tego czasami, bo "to jest bardziej czytelne"

Nie jest, ale dla początkujących może jest?

Nie używam ale nie mam problemu jak ktos to robi.

No ja właśnie lubię taki explicit zapis ale tylko w momencie, gdy nazwa boola jest taka niejednoznaczna, że to bool. Najczęściej robię to w jakimś LINQ. W takich prostych ifach, jakie podałeś raczej mi się nie zdarza.

Nie stosuje:

collection.All(element => element.IsValid)

Czasami stosuje, w sytuacjach gdy nazwa zmiennej trochę jest taka, że nie jestem po nazwie w stanie stwierdzić, że to bool a nie mogę jej zrefaktoryzować:

collection.All(element => element.Check == true)

Koniec końców ma to poprawiać czytelność - jeśli taki zapis sprawia, że według mnie coś jest bardziej czytelne to go wprowadzam. Najwyżej w Code Review wyjdzie, że tylko dla mnie to jest bardziej czytelne a reszta uważa za Code Smell :P

Zgadzam się z przedmówcami:

• zapis xxx == true wcale nie jest czytelniejszy
• jeśli jednak jest, to znaczy, że mamy problem z nazwami zmiennych/funkcji
• dobrze nazwana zmienna (albo funkcja, która zwraca bool) powinna sama się opisywać - czyli być w stylu isEmpty albo enabled czy active. Wtedy nie ma żadnej potrzeby pisania if (element.isActive == true) bo samo if (element.isActive) jest wystarczająco opisowe
• sam staram się nie używać takiego zapisu
• jak ktoś tak zrobi to nie mam problemu, ale raczej sugeruję wtedy zmianę. Albo chociaż pytam, z czego to wynika (bo może mieć jakieś uzasadnienie)

cerrato napisał(a):

Zgadzam się z przedmówcami:

• zapis xxx == true wcale nie jest czytelniejszy
• jeśli jednak jest, to znaczy, że mamy problem z nazwami zmiennych/funkcji
• dobrze nazwana zmienna (albo funkcja, która zwraca bool) powinna sama się opisywać - czyli być w stylu isEmpty albo enabled czy active. Wtedy nie ma żadnej potrzeby pisania if (element.isActive == true) bo samo if (element.isActive) jest wystarczająco opisowe
• sam staram się nie używać takiego zapisu
• jak ktoś tak zrobi to nie mam problemu, ale raczej sugeruję wtedy zmianę. Albo chociaż pytam, z czego to wynika (bo może mieć jakieś uzasadnienie)

No ale ja staram się być oszczędny i np w pytonie używam jednej zmiennej gdzie raz ona jest bool, raz string, a raz int? To jak ja nazwać ? No i if na string oznacza coś innego niż if na bool czy int?

Pytanie w jakim kontekście. W C# jest to uzasadnione w przypadku bool? (czyli Nullable<bool>). Jest on wtedy trójwartościowy (true, false, null). W takim przypadku if (variableName) == false jest jak najbardziej na miejscu. W innych przypadkach traktuję to jako błąd.

S4t napisał(a):

No ale ja staram się być oszczędny i np w pytonie używam jednej zmiennej gdzie raz ona jest bool, raz string, a raz int? To jak ja nazwać ? No i if na string oznacza coś innego niż if na bool czy int?

odnośnie To jak ja nazwać - mam parę pomysłów:

• jesteś trollem
• masz syf w kodzie
• to jest prowokacja, i do tego marnej jakości
• robisz sobie jaja
• zatrudniasz hindusów :D

cerrato napisał(a):

S4t napisał(a):

No ale ja staram się być oszczędny i np w pytonie używam jednej zmiennej gdzie raz ona jest bool, raz string, a raz int? To jak ja nazwać ? No i if na string oznacza coś innego niż if na bool czy int?

odnośnie To jak ja nazwać - mam parę pomysłów:

• jesteś trollem
• masz syf w kodzie
• to jest prowokacja, i do tego marnej jakości
• robisz sobie jaja
• zatrudniasz hindusów :D

IMHO To jest benefit tego że w pythonie każdny może programować. Zwłaszcza matematycy dla których zmienna a jest jak najbardziej normalna XD (więc styl kodowania leży w tym języku :P )
Niby w Haskellu jest podobnie że matematycy popisali tam biblioteki gdzie zmienne są a b c d, ale jak jest statyczne typowanie z wypisanymi typami to jeszcze da się z tym żyć XD (BTW uwielbiają też tak nazywac generyki, a nie jakieś tam jak w Javie T1 T2 T3 :D )
Chociaż jak teraz dla zabawy czytałem przykłady kombinatorów to kody w stylu \ a b c d -> a (b d) (c d) czyta się specyficznie, a najgorsze jest to że człowiek po miesiącu się przyzwyczaja XD

cerrato napisał(a):

S4t napisał(a):

No ale ja staram się być oszczędny i np w pytonie używam jednej zmiennej gdzie raz ona jest bool, raz string, a raz int? To jak ja nazwać ? No i if na string oznacza coś innego niż if na bool czy int?

odnośnie To jak ja nazwać - mam parę pomysłów:

• jesteś trollem

Bywam

• masz syf w kodzie

Tak, ale to kod odziedziczony

• to jest prowokacja, i do tego marnej jakości

Może trochę prowokacja, ale z jakością przesadziłeś

• robisz sobie jaja

Jakoś trzeba sobie umilać to smutne jak piz... życie programisty

• zatrudniasz hindusów :D

Kod pisali prawdziwi Polacy.

W tym chodzi o to że nie piszemy dla siebie tylko dla potomnych, i jak dla kogoś napisanie że coś sie równa true daje lepsza czytelność to niech tak robi, nie ma to żadnego wpływu na wydajność i jakoś diametralnie kod też się nie rozrasta,.

KamilAdam napisał(a):

cerrato napisał(a):

S4t napisał(a):

No ale ja staram się być oszczędny i np w pytonie używam jednej zmiennej gdzie raz ona jest bool, raz string, a raz int? To jak ja nazwać ? No i if na string oznacza coś innego niż if na bool czy int?

odnośnie To jak ja nazwać - mam parę pomysłów:

• jesteś trollem
• masz syf w kodzie
• to jest prowokacja, i do tego marnej jakości
• robisz sobie jaja
• zatrudniasz hindusów :D

IMHO To jest benefit tego że w pythonie każdny może programować. Zwłaszcza matematycy dla których zmienna a jest jak najbardziej normalna XD (więc styl kodowania leży w tym języku :P )

Dokładnie taki jest problem, to akurat byli tak zwani Data endżinery, musiałbym się ostro starać, żeby wymyślić skomplikowanie niektórych rozwiązań,

Ja uzywam dluzszego zapisu, poniewaz moim zdaniem if(publishMessage == false) jest czytelniejsze niz if(!publishMessage) - ! latwo przeoczyc. I dla spojnosci robie to rowniez dla sprawdzania == true.

throwaway_007 napisał(a):

Ja uzywam dluzszego zapisu, poniewaz moim zdaniem if(publishMessage == false) jest czytelniejsze niz if(!publishMessage) - ! latwo przeoczyc. I dla spojnosci robie to rowniez dla sprawdzania == true.

Jak wcześniej wspomniano, odpowiednie nazewnictwo pozwala uprościć kod i poprawić jego czytelność. if (messagePublished), ewentualnie if (messageIsPublished) będzie już wystarczająco czytelne.

No i ciężko tutaj tłumaczyć się zauważalnością operatora !, który jest też używany jako obietnica programisty, że wynikiem wywołania nie będzie null.

w takim php będzie różnica czy porównujemy if($a == TRUE ) czy if($a === TRUE) czy if($a) jak $a będzie np. stringiem

Nie wydaje mi się ze zmiana nazwy zmiennej poprawi czytelność, raczej zmieni sens bo "messagePublished" to nie synonim "publishMessage" ;) Tak czy inaczej chodzi mi o czytelność operatora !.

Ferdynand Lipski napisał(a):

Jak wcześniej wspomniano, odpowiednie nazewnictwo pozwala uprościć kod i poprawić jego czytelność. if (messagePublished), ewentualnie if (messageIsPublished) będzie już wystarczająco czytelne.

https://pl.wikipedia.org/wiki/Notacja_w%C4%99gierska

W moim odczuciu wygląda to jakoś błędnie. Trochę jak

if(isTrue)
  return true;
else
  return false;

Jeśli jest potrzeba porównywania boola do true, to najprawdopodobniej mam do czynienia z juniorem/stażystą, któremu trzeba po prostu wytłumaczyć dlaczego jest to niepotrzebne.

Zależy w jakim języku:

• jeśli java, Kotlin, c#, taki gdzie wiemy że zmienną to bool - to oczywiście kategorycznie nie. Niepotrzebna operacja i trudniejszy zapis do przeczytania.
• jeśli js, php, Python, gdzie zmienne mogą mieć różne typy, to czasem to jest konieczne żeby przyrównać coś do == true i wtedy nie da się tego obejść

Poza tym, cenie sobie spójność w kodzie,więc jeśli ktoś miałby pisać if (isActive == true), to powinien też pisać np setIsActive(isActive == true), co ma jeszcze mniej sensu.

throwaway_007 napisał(a):

Nie wydaje mi się ze zmiana nazwy zmiennej poprawi czytelność, raczej zmieni sens bo "messagePublished" to nie synonim "publishMessage" ;) Tak czy inaczej chodzi mi o czytelność operatora !.

Jak masz problem z tak banalnym elementem jak zaprzeczenie, do tego stopnia że uważasz go za nieczytelny, to rozwiązaniem na to nie jest dodawanje == false, tylko programowanie dużo więcej i obycie się z językiem.

Są języki takie jak Python gdzie operator zaprzeczenia to not zamiast !, ale to jest jakby cukier składniowy - nie ma jakiejś zasadniczej różnicy.

Na szczęście nikt do tej pory nie próbował mnie w pracy przekonywać, że isActive == true jest czytelniejsze.

S4t napisał(a):

Nie używam ale nie mam problemu jak ktos to robi.

To jest słabe. Koniec końców z zespole powinien być ustalony standard kodowania, jak ktoś pisze do szuflady to może robić co chce, ale później przyjdzie do pracy i zacznie jęczeć, że mu źle się czyta. Lepiej jest utrzymywać w społeczności pewne standardy, a standardem w tym kontekście jest niepisanie zbędnego kodu.

No ale jak nie jest ustalony to co zrobisz.

nie używam i nie uważam, żeby było czytelniejsze. W moim subiektywnym odczuciu jest to mało eleganckie.

Riddle napisał(a):

throwaway_007 napisał(a):

Nie wydaje mi się ze zmiana nazwy zmiennej poprawi czytelność, raczej zmieni sens bo "messagePublished" to nie synonim "publishMessage" ;) Tak czy inaczej chodzi mi o czytelność operatora !.

Jak masz problem z tak banalnym elementem jak zaprzeczenie, do tego stopnia że uważasz go za nieczytelny, to rozwiązaniem na to nie jest dodawanje == false, tylko programowanie dużo więcej i obycie się z językiem.

Rozumiem i akceptuje ze jestem w mniejszości, ale sugerowanie żeby programować więcej jest nie trafione. Programuje dużo i od dawna i taka jest moja preferencja.

Dla mnie jest to rowniez spojnie z innymi rodzajami instrukcji warunkowych - np. if(a == b), if(a == null), if(a == Enum.A)

Jeśli komuś wygodniej zapisać if(variable == true), to niech tak pisze.
Wiadomo, że warunek w if() będzie wartością true lub false, nic innego tam nie wrzucisz, więc nawet w sytuacji gdy masz if(method()) wiesz, że metoda musi zwracać boola.
Takie zapisy nie zmniejszają czytelności ani jej nie zwiększają, takie dodatkowe porównanie pewnie nawet nie niesie za sobą dodatkowego obłożenia w kontekście zużycia zasobów (aż z ciekawości zrobię sobie jakieś benchmarki).
Reasumując kwestia gustu.

Riddle napisał(a):

Gdybyś faktycznie programował dużo - i mam na myśli tutaj w różnych językach

To dużo czy w róznych jezykach ;)

if (something == true == true == true)
I nie masz żadnego argumentu przeciwko temu zapisowi, bo każdy argument przeciwko niemu, to jest też argument przeciwko if (x == true).

Wydawało mi się ze mówimy o czytelności, a nie o tym czy zapis można zredukować do prostszej formy. Bo te rzeczy są często ze sobą rozbieżne.
Poza tym nie rozumiem dlaczego na sile próbujesz mi udowodnić ze nie mam racji. Napisałem jaka jest moja preferencja, każdy może mieć swoja.

Poza tym, faktyczna rozmowa chyba jest mniej programistyczna a bardziej taka "socjologiczna", bo to co opisujesz to (dla mnie przynajmniej) wygląda jakbyś miał pewien schemat , że if musi mieć formę

if ({argument} {operator} {argument})

I dlatego Ci nie pasuje zapis z ! albo bez ==true.

Tymczasem if wygląda tak:

if (bool)

Z tą różnicą że zazwyczaj kiedy uczymy się programować, to jedynym boolem który wchodzi do ifa to są takie proste wyrażenia z ==, co wyjaśnia czemu czasem ktoś może wytworzyć sobie w głowie taką preferencję do wzorca if ({argument} {operator} {argument}).

No bo zastanówmy się, mówisz że nie lubisz zapisu !? To weźmy zapis że chcesz odwrócić zmienną - wtedy, jakiego zapisu byś użył?

bool active = !suspended;

Czy

bool active = suspended == false;

?

Bo jeśli użyłbyś pierwszego, to w takim razie jednak lubisz ! ;>

throwaway_007 napisał(a):

if (something == true == true == true)
I nie masz żadnego argumentu przeciwko temu zapisowi, bo każdy argument przeciwko niemu, to jest też argument przeciwko if (x == true).

Wydawało mi się ze mówimy o czytelności, a nie o tym czy zapis można zredukować do prostszej formy. Bo te rzeczy są często ze sobą rozbieżne.
Poza tym nie rozumiem dlaczego na sile próbujesz mi udowodnić ze nie mam racji. Napisałem jaka jest moja preferencja, każdy może mieć swoja.

Nie, to bardziej wygląda jak brak obycia. if przyjmuje po prostu bool - nie ma powodu żeby dodawać do niego niepotrzebne (zbędne) kawałki.

cerrato napisał(a):

Zgadzam się z przedmówcami:

• zapis xxx == true wcale nie jest czytelniejszy
• jeśli jednak jest, to znaczy, że mamy problem z nazwami zmiennych/funkcji

Dziś (i od dawna) piszę bez == true ale pamiętam dawne czasy, kiedy sobie głosem czytałem. To mnie szybko przyprowadziło do wspomnianego punktu i zinternalizowało
Przy czym w obu jezykach, ze zmiennymi po polsku lub angielsku
"if samochód isenejbled then"

Użycie ==true jest wyraźnym wskaźnikiem jak autor się spocił z wysiłku, w sąsiednim kodzie z podniesioną czujnością oczekuję np zgubienia się w prawach de Morgana.
(Akceptuję sytuacje C# nullalble bool czy inne mocno uzasadnione)

Nie jest czytelniejsze dla każdego, kto zdaje sobie sprawę, że if działa na booleanie. Jedyny wyjątek, to programiści bardzo starego C i własne, "lepsze" typy logiczne. Dla mnie czystej postaci pleonazm, do tępienia podczas review.

Czasem. Dużo zależy od nazwy zmiennej bo np. if (someValue == true) wygląda trochę lepiej niż if (someValue).
Ale to są raczej wyjątki od reguły, wolę jednak mieć nazwy, które coś znaczą - wtedy nie trzeba tego dodawać (np. if (valid))

"to zalezy"

Np kiedyś dostałem do wyciagnięcia z gó... / zapaści / "powiedzcie czy coś da się zrobić" projekt gdzie w includach było

#define true 0
#define false 1

W takim kodzie wspomnianej notacji KONIECZNIE trzeba było używać.
(Demiurgiem tego świata chyba był słaby pascalowiec / delfista siłą / kasą / łopatą / obietnicą w CV zmuszony do klepania C/C++)
Ale może pomyliłem demiurga z delirium