Czy zrobić coś wielkiego z == prawda?

Jest mój kolega, który nieustannie pisze:

if (someBool == true)

Doprowadza mnie do ściany! Czy powinienem to zrobić, czy po prostu porzucić?

To tylko zbędny kod, a nie życie lub śmierć. Jednak....

Jeśli to się często zdarza, problem może wynikać z tego, jak someBoolsię nazywa. Dobre imię może znacznie przyczynić się do wyeliminowania potrzeby==true

if(IsSomeCondition)

lub

if(hasCondition)

lub

if(somethingExists)

na przykład.

Kiedy widzę someBool == true, nie mogę się powstrzymać, ale czuję, że programista nie zinternalizował koncepcji oceny , co jest dość zasadniczą wadą.

Jednak moja perspektywa jest wypaczona, ponieważ spędziłem kilka lat na studiach programistycznych dla dzieci, które często pisały takie wyrażenia, ponieważ naprawdę nie opanowały mentalnego ćwiczenia oceny wyrażeń. Po zapoznaniu się z koncepcją redundancja stała się oczywista.

W przypadku innego kompetentnego programisty prawdopodobnie tak nie jest. Prawdopodobnie jest to po prostu zły nawyk, który rozwinęli na początku programowania i nigdy się nie trzęsli. Ale nadal by mnie to trochę przestraszyło, gdyby to była pierwsza rzecz, jaką zobaczyłem w rozmowie.

To też doprowadza mnie do szaleństwa, ale powiedziałbym, że wspominam o nadmiarowości w konstruktywny sposób, a potem porzucam ją, nawet jeśli się nie zgadzają.

Alternatywnie możesz wypróbować to podejście:
Ty: Czy możesz zacząć używać następującej konwencji kodu do oceny wartości logicznych?

if (someBool==true)&&(true==true) {}

One: Dlaczego mielibyśmy to robić? Druga połowa tego stwierdzenia jest zbędna, zawsze ocenia się ją na prawdziwą.

Ty: George, masz rację. Głupi ja. Przejdźmy więc do wersji bez nadmiarowości. Co powiesz na?

if (someBool) {}

Myślę, że jeśli coś tak trywialnego jest twoim największym problemem ze współpracownikami, powinieneś uważać się za szczęściarza.

Zdecydowanie powinieneś powstrzymać ten zły nawyk. Łagodnie...

Łatwo zapomnieć o napisaniu podwójnych znaków równości, zamieniając kod w:

if (someBool = true)

Na przykład w języku C # spowoduje to wygenerowanie tylko ostrzeżenia, a nie błędu. Więc jeśli nie traktujesz ostrzeżeń jako błędów, kod będzie działał, ustaw zmienną na true i zawsze wprowadź warunek.

Zgadzam się z tobą, ale zamierzam zagrać tutaj w adwokata diabła:

W zależności od języka i nazwy zmiennej odpowiednie jest x == true:

Rozważ następującą sytuację w języku ze statycznym pisaniem i wymuszaniem typów dla typów integralnych:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Ktoś czytający tę sekcję kodu może nie od razu zdać sobie sprawę, że akcjeAllowed to zmienna boolowska - może to być również liczba całkowita reprezentująca liczbę dozwolonych akcji. Więc dodając == true, staje się jasne, że x jest wartością logiczną, a nie liczbą całkowitą wymuszaną na wartość logiczną:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

Co z zerowalnymi boolami?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

Zazwyczaj nie chcesz robić nic wielkiego z konwencji kodowania, chyba że wspomniana konwencja w jakiś sposób utrudnia projektowi znaczący wpływ. Widziałem wiele gorących sporów o rzeczy tak małe jak regiony kodu i wiodące podkreślenia.

Biorąc to pod uwagę, nie widzę problemu z dodawaniem == truedo instrukcji warunkowej. W rzeczywistości mam zwyczaj używania == falsew przeciwieństwie do wiodącego wykrzyknika podczas testowania w warunkach ujemnych. Myślę, że to bardziej czytelne.

Jeśli istnieje ustalona konwencja, mówię ją przestrzegaj, chyba że istnieje powód do zmiany. Jednak naprawdę nie warto podnosić wielkiego smrodu.

Ack. Jestem tym facetem. Wstyd, wstyd. Tak się nauczyłem i tak „automatycznie formatuję” w mojej głowie. Używam preferowanej składni Joela tylko wtedy, gdy zmienna bool ma przedrostek czasownika, taki jak „is”. Potrzebuję czasownika, czy to „jest”, „może”, „zrobił”, czy też potrzebuję ==, aby podać czasownik „równa się”. Mogę nigdy nie zerwać z tym nawykiem, więc zrozumiem, jeśli na ulicy nie przywitasz się ze mną.

przypominają mi „boolowski kod szaleństwa”, jest taki jak te

if(someBool == true)
   otherBool = false;
else
   otherBool = true

Zamiast:

 otherBool = !someBool

Osobiście bardzo nie lubię sposobu mówienia „nie” w językach opartych na C. Ten mały wykrzyknik jest zbyt łatwy do przeoczenia.

Dlatego piszę to w całości:

if (someCondition == false) {

Po przeczytaniu tego przez chwilę chcę też symetrii z

if (someCondition == true) {

Więc rozważ to jako artefakt użycia C !zamiast not.

To zależy od języka, ale zwykle jest to zły pomysł ...

W C nigdy tego nie rób. Zbyt łatwo jest znaleźć sytuację, w której testowana wartość nie jest fałszywa (niezerowa), ale również nie jest równa pojedynczej wartości zdefiniowanej jako „prawda”.

W Ruby, rób to tylko wtedy, gdy masz absolutną pewność, że chcesz zawieść we wszystkim oprócz Boolean true.

W C ++ i innych językach statycznych z typem bool jest zbędny i może prowadzić do błędów programistycznych przy błędnym pisaniu =zamiast ==lub błędów promocyjnych, jak wspomniano w komentarzach.

Myślisz że to źle? Co powiesz na:

if(someCondition) {
  return true;
} else {
  return false;
}

wolę

if (bVal)

lub

if (!bVal)

ale obawiam się, że podniesienie go wkurzy ludzi, więc radzę o tym zapomnieć. Przepraszam!

powinieneś mu powiedzieć, że robi to źle.

jego

if (true == someBool) {

}

jeśli kiedykolwiek zapomni o jednym = ma duże problemy ze stylem pisania.

Co powiesz na

if (x == "true")

DLACZEGO TO STRING ?!

W rzeczywistości, jeśli jest zerowy, konieczne byłoby przetestowanie dla x == true. :)

Piszę taki kod!

Oto dlaczego:

„if bla == true” brzmi jak zdanie, gdzie jako „if bla” w wielu przypadkach nie. To po prostu brzmi źle, gdy CZYTANIE rzeczywistego kodu.

Kompilator ostrzega również o przypisaniach w blokach if, więc użycie naprawdę == true nie jest niebezpieczne. (myląc to z =)

Czy też faceci, którzy nie piszą „== true”, używają tego „! ()” Dla „== false”? Uważam to za naprawdę brzydkie. A jeśli użyjesz „== false”, to tylko bardzo spójne jest użycie „== true”, zamiast mieć dwa różne sposoby weryfikacji prawdy.

Pamiętaj, że pracujesz w zespole, więc musisz wypracować te rzeczy razem. „Gra z innymi miłymi” nadal jest ważną cechą osobowości nawet po szkole podstawowej :)

Zasadniczo pominie „== prawda”, ale nie warto poświęcić nawet minuty na omówienie go, chyba że uwzględnisz go w standardach kodowania twojego zespołu.

Chociaż zgadzam się jako programista głównie w języku C #, nie mogę powiedzieć, że zawsze tak jest. Na przykład w Javascripcie === wykona koalescencję typu. Więc zakładając var x = 3, to:

if(x) --> true

podczas

if (x === true) --> false

Myślę, że różni się to od ==, ponieważ nawet w JS nie użyłbym, jeśli (x == true), ale po prostu coś do przemyślenia.

Ten rodzaj dotyku dotyczy innej kwestii, która pojawiła się w moim biurze:

bool b = false;

W języku C #, bool b; wystarczy i zainicjuje b na false . Jednak bardziej wyraźne jest napisanie powyższej linii i tak czy inaczej kompilator powinien ją zgrać podczas optymalizacji.

Myślę, że moim celem jest to, że nie zawsze jest tak oczywiste, co jest i nie jest dobrą praktyką, a wiele z nich sprowadza się do preferencji, a także cech / dziwactw językowych.

Ach tak, ale co jeśli zmienna ma wartość zerową? (bool?)

Niektóre języki (C #) będą wymagać i obsadzać lub porównywać z „true”.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

Młodzi znają zasady, a starzy znają wyjątki;)

Najpóźniej C#, jeśli masz do czynienia z null-able bool, musisz:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Jeśli tristate nie stanowi problemu, zwykle nie powinno być powodu, aby porównywać coś do true/ True. Jednak w Pythonkilku innych językach, takich jak np. C/C++, Można wykonywać ifwyrażenia inne niż bool. Te języki mają unikalne reguły interpretowania liczb całkowitych, wskaźników, list itp. Jako prawda lub fałsz. Czasem tego nie chcesz. Na przykład w tym fragmencie kodu w języku Python:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Tutaj zpowinno być True, ale z2powinno być False. Teraz Clojurejęzyk podchodzi do tego w jeszcze inny sposób - andfunkcja nie musi być oceniana na a bool, ale ifmoże sobie z tym poradzić.

Niezależnie od języka, za każdym razem, gdy porównujesz coś do Truelub False, prawdopodobnie warto to skomentować.

Takie kodowanie też wcześniej mnie potarłoby. Chociaż twój przykładowy identyfikator nosi nazwę „someBool”, nieumyślne użycie tego stylu kodowania w zmiennej, która nie była gwarantowana jako logiczna, może spowodować niezamierzone zachowanie. Jeśli wartość „someBool” nie jest dokładnie „prawda” lub „fałsz”, wynik będzie fałszywy.

W ubiegłym roku spotkałem bardzo subtelny błąd spowodowany takim stylem kodowania, który był trudny do zidentyfikowania, ponieważ oczy błyszczą nad takimi konstrukcjami. Pomyślałbyś: „Jak to może być źle?” To samo dotyczy tak dobrze rozumianych wyrażeń, jak „(var)” lub „(! Var)”, że czytasz je lub kodujesz bez sprawdzania ich zachowania.

Wprowadziłem więc kilka standardów kodowania, aby ograniczyć istnienie takich błędów w bazie kodu i prawdopodobieństwo, że takie subtelne błędy przypadkowo wkradną się w przyszłości.

1. Wszystkie wyrażenia muszą być nawiasowane zgodnie z ich zamiarem.
2. Wszystkie testy boolowskie muszą być wyrażone negatywnie, np. „SuchBool! = False”.

Usuwając kod niezgodny z nowym stylem, zidentyfikowałem i poprawiłem kilka kolejnych takich subtelnych błędów.

Musiałem używać tego cały czas w ActionScript 2 (co prawda teraz martwy język), ponieważ:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Tak więc prawie zawsze najlepiej było być konkretnym.

Zgadzam się. Jest to zbędna konstrukcja, szczególnie w silnie pisanych językach.

Aby dodać kolejne niewłaściwe użycie boolanów, kilka razy znalazłem tego rodzaju konstrukcję w Javascript (szczególnie przy niektórych funkcjach potworów podobnych do spaghetti, jak w ponad 100 liniach):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Wygląda na to, że z powodu braku ścisłej definicji typu w tym języku niektórzy programiści wolą nie bawić się false|undefinedwartościami.

Mam kolegę, który będzie miał taki kod:

if(something == true)

A potem, dla pewnego rodzaju testu / debugowania, nie będzie chciał wywoływać tego bloku, więc zmieni go na:

if(something == true && false)

A potem od czasu do czasu zmieni to na:

if(false)

Najgorsze jest to, że ten rodzaj debugowania czasami się na mnie ściera i jest naprawdę zły dla innych programistów!

Powiedziałbym, że spójność jest królem w bazie kodu. Dlatego powinieneś używać stylu, który jest najczęściej używany w twojej organizacji. Postaraj się, aby Twój ulubiony styl był częścią oficjalnych wytycznych kodowania firmy. Jeśli jest już w wytycznych, postępuj zgodnie z nim.

(To powiedziawszy, to też naprawdę mnie drażni - ale prawdopodobnie nie wystarczy, aby zrobić z tego wielką sprawę).

Wolę nie umieszczać dodatkowego == true, ale czasami przypadkowo go dołączam i nie zauważam. Osoba mogła ich nie zauważyć i przypadkowo je umieścić. Ponownie czytam kod i czasami zauważam, że umieściłem dodatkowe == true, więc usuwam to == true. Czasami tego nie zauważam iz radością witam kogoś, kto mówi mi, że umieściłem go niepotrzebnie.

Co powiesz na:

int j = 1;
for (int i=1; i>=j; i++) ...

Tak, widziałem to.