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

Czytelne i poprawne to:

if(true == SomeVar)

lub

if(true === SomeVar)

ccwrc napisał(a):

Czytelne i poprawne to:

if(true == SomeVar)

Yoda conditions XD XD XD

lub

if(true === SomeVar)

Ale temat oryginalnie dotyczył C# a tam raczej nie ma ===?

Ja piszę głównie w mhrocznym języku, jakim jest C++, więc jak widzę gdzieś zmienna == true, to się muszę zastanowić, czy autor nie używa jakichś cudów na kiju… Zatem nie przepuszczę czegoś takiego przez code review — ani jak to zamieszanie jest przypadkowe (tzn. wystarczyłoby samo if (zmienna)), ani gdy jest celowe.

Jeśli z nazwy zmiennej wynika że to bool np: is_valid to nie.
Jeśli zmienna jest niejasna np error to w środku może być True albo {"status": "error"} albo "Cos poszlo nie tak" albo cokolwiek wtedy wole jasne porównanie.

Jeżeli w języku do ifa możesz wrzucić nie tylko boola i zostanie to zrzutowane na truthy to stosowanie explicit porównania ma sens, a jeżeli jest to np. C# i nienullowalny bool to nie bardzo.

Taki zapis wynikać może z niezrozumienia do końca działania typu logicznego i niepotrzebnie wydłuża kod źródłowy, a (o ile nie ma optymalizacji) także wynikowy. Chyba, że w dziwnych językach - PHP, C# - gdzie z pewnych powodów takie porównanie do true bądź false jest konieczne, oraz w pewnych dziwnych sytuacjach. Taką dziwną sytuacją może być na przykład zdefiniowanie makr TRUE i FALSE z założeniem, że mogą mieć one dowolne (różne) wartości, inne niż 1 i 0, a cały program musi się do tego dostosować. I wtedy konieczne byłyby zapisy rodzaju if (x == TRUE), x = (y < z) ? TRUE : FALSE; itp., ale zasadniczo takie wymaganie jest głupie i rzecz jasna niespotykane. A co do przypisania zmiennych logicznych, to zdarza się jeszcze zapis jak poniżej, zamiast prostego przypisania:

if (p == true)
        q = true;
else
        q = false;

Nie, nigdy, bałbym się pracować z kimś, kto tak robi, bo albo nie ogarnia języka, albo przepisuje kod z jakiejś antycznej książki do C.

W sumie jak komuś brakuje czytelności, to można pójść jeszcze krok dalej:

public bool IsTrue(bool valueToCheck) 
{
  if(valueToCheck == true)
    return true;
  else
    return false;
}

Potem można bezpiecznie w naszym ifie użyć:

if(IsTrue(boolToCheck)) 
{
  [...]

Ewentualnie żeby było hiperczytelne:

if(IsTrue(boolToCheck) == true) 
{
  [...]

Można skorzystać też ze switch expression w naszej metodzie, żeby bardziej uwydatnić bezsensowność naszego rozwiązania:

public bool IsTrue(bool valueToCheck) 
{
  return valueToCheck switch
    {
        true => true,
        false => false
    };
}

Co ważne zaznaczam, że taka weryfikacja może mieć jakiś sens z typem nullable, ale wtedy bardziej bym się zastanawiał dlaczego nasza 'flaga' może przyjmować nulla i czy nie trzeba w innym miejscu poprawić. Ah no i mowa o C z płotkiem, w innych językach sprawa może wyglądać inaczej :)

Czym to się człowiek nie zajmie, żeby nie pracować

Nie. Jedyny wyjątek to: if (dupa?.JakisBool == true) aczkolwiek i tak 9/10 preferuje bezposredniego null checka bo IMO mniej trzeba myśleć co kod robi (dla kontrastu if (dupa?.JakisBool != false))

Sarrus napisał(a):

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.

Nie na miejscu jest to, że to się w ogóle skompiluje. Nie można porównywać do siebie wartości różnych typów, w tym wypadku bool i Nullable<bool> bo takie porównywanie zwyczajnie nie ma sensu. Ciekawe czy można też porównywać bool do List<bool> bo to w zasadzie to samo.

Idąc tym tokiem rozumowania to w C# pewnie można i tak:

List<bool> list;
if(list==false) 
....

Co do tematu. Nie, nie ma potrzeby przedłużać zapisu.

gajusz800 napisał(a):

Nie na miejscu jest to, że to się w ogóle skompiluje. Nie można porównywać do siebie wartości różnych typów, w tym wypadku bool i Nullable<bool> bo takie porównywanie zwyczajnie nie ma sensu.

Ma jak najbardziej sens, bo jeśli Nullable<bool> ma wartość, to jest ona typu bool, więc da się to porównać bez problemu.

Ciekawe czy można też porównywać bool do List<bool> bo to w zasadzie to samo.

W sensie dla Ciebie jedna zmienna i kolekcja zmiennych to to samo?
Udany weekend widzę masz.

@somekind: bardzo ładnie wyjaśniasz wątek :D
Niemniej nie wiem po co ciągnąć temat.
Niezależnie od języka if rozpatruje warunek bool i... kropka.
jeśli jest true to wpadamy w if-a jeśli nie, to lecimy dalej.
Kwestia sporna.

W jednym projekcie w django miałem zmienną bool gdzie null również był częścią logiki, więc trzeba było sprawdzać czy jest true, false czy null. Było to tak świetnie zrobione, że przy edycji z poziomu django admina, nie można było wybrać null. Zmieliliśmy to już na coś bardziej sensownego.

still.still napisał(a):

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".

jak to możliwe, że jest dla Ciebie mało czytelne, jak od razu widać, że przyrównujesz czy zmienna równa jest true ? Zapis z wykrzyknikiem jest o tyle tricki, że możesz faktycznie go nie przyuważyć. Tutaj masz czarno na białym. Poza tym najlepiej w teamie ustalić sobie pewne konwencję, których team będzie się trzymał. Nie każdemu będzie to pasować, ale nie ma nić gorszego, jak w myśl zasady każdy sobie i powstaje totalny miszmasz

no tak team bootkampowców ma se ustalać zasady, i wtedy mogą być pewni posady, bo nikt normalny do nich nie dołączy

dawiddawido napisał(a):

Zapis z wykrzyknikiem jest o tyle tricki, że możesz faktycznie go nie przyuważyć

Dlatego proponuję zrobić funkcję (metodę statyczną) exclamationMark i nikt nie przeoczy:

def exclamationMark(b: Boolean) = !b

i potem już piszesz:

 if (exclamationMark(variableName))

Ale jednak lepiej byłoby tak:

if (exclamationMark(variableName) == true)

Wtedy już na pewno nie przeoczysz.

Lub jeszcze lepiej:
if (exclamationMark(variableName) == exclamationMark(false))