Czy zrobić coś wielkiego z == prawda?

105

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

if (someBool == true)

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

JoelFan
źródło
12
Wolę jawne, if (some_flag == true)ale niejawne if (is_something)lub if (has_something). Zanotuj nazwy zmiennych.
fredoverflow 18.10.10
69
Przypomnij swojemu współpracownikowi, że ten typ someBool == truejest również logiczny, więc zgodnie z tą samą logiką powinien być if ((someBool == true) == true).
Mike Seymour,
2
@GSto: Podejrzewam, że o tym wiesz, ale w PHP możesz to zrobić, aby „rzucić” wszystko na bool i może być faktycznie przydatne.
zneak 19.10.10
2
@zneak Lub możesz być jaśniejszy i używać $var = (bool) some_expression. W większości przypadków nie ma to nawet znaczenia, ponieważ PHP wykona niezbędne konwersje dynamicznie.
waiwai933,
4
zawsze najpierw sprawdzaj stałą, jeśli (true == someBool), na wypadek, gdyby przypadkowo wpisałeś = zamiast == [tak, żartuję!]
Steven A. Lowe

Odpowiedzi:

126

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.

Robert Harvey
źródło
To dla mnie najbardziej prawdziwe. Chodzi o przejrzystość i sztukę nazewnictwa, oryginalna składnia nie jest taka zła, ale jest to właściwa ścieżka do lepszego kodu.
TJB,
2
Pokonaj mnie do tego! Bez odpowiedniego nazewnictwa bardziej zwięzła równoważność nie ma żadnego sensu.
Troy Hunt
4
Musiałem kilkakrotnie użyć someBool == truestarszego kodu dla zachowania przejrzystości. Ale jeśli piszę od podstaw, odpowiednio if (isSomething)
nazywam
Zgadzam się, mimo że nazewnictwo to rozwiązałoby, zakładając, że nazywa się SomeBool, może to znaczyć cokolwiek i być dowolnego rodzaju (liczba całkowita równa liczbie boolanów w tablicy?). Booleany potrzebują jakiegoś czasownika egzystencjalnego, bo inaczej zawsze będą trudne do odczytania.
Morgan Herlocker,
Zgadzam się, chodzi o czytelność. Jeśli zmienne są dobrze nazwane, nie potrzebujesz ich. Jeśli wyrażenie brzmi lepiej z nim, wybrałbym „== true”, to również jest spójne, jeśli użyjesz „== false” zamiast (brzydkiego) „if (! ())”.
Ronny Brendel,
71

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.

Tim Goodman
źródło
Nie nazwałbym tego tak szybko nawykiem. Słyszałem kilka naprawdę oszałamiających rzeczy z ust profesjonalnych programistów. Zwykle wkrótce potem jeden z grokerów: „jak to w ogóle działało?”
dash-tom-bang
12
Z całego serca zgadzaj się na ocenę. Czasami zastanawiałem się: „Gdzie to się kończy?” if ((((x == true) == true) == true)! = false) // i tak dalej ...
yawmark 19.10.10
1
Czasami pisałam if (c == true) return true; else return false;, ale 99% czasu (1% jest, ponieważ nigdy nie mogę być pewien, że czegoś nie przegapiłem) natychmiast zauważę i zastąpię to wszystko return c. Spodziewam się, że najbardziej kompetentni programiści powinni zrobić coś podobnego, jeśli rozwiną nawyk na początku swojej kariery. Nie spodziewałbym się odpowiedzi wtf.
Lie Ryan,
1
O, chłopcze, sztuka myślenia. I dosłownie natknąłem to w naszym kodzie w zeszłym tygodniu. if (!someCondition) { someCondition = false; }Widziałem kilka (eee, wiele) zwolnień, a także pewne niemożliwości w naszym kodzie, ale ten był tak prosty, ale tak irytujący, że ktoś go napisał. Nawet wiele razy.
Anthony Pegram,
1
Zauważ tylko, że widziałem kilka przypadków, if(x) x=true;które NIE były zbędne, ale raczej odpowiadały x=!!x;(normalizując x do 0/1)
jkerian
58

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) {}
JohnFx
źródło
6
Tak, zgodziłem się. To głupie, ale musisz wybrać swoje walki, a ten kod rzeczywiście robi to, co robi twój kolega. Wspomnij o tym w „Nie do diabła z tobą ?!” w pewien sposób, a następnie upuść. Chociaż jeśli zaczną ciągnąć bzdury, takie jak „if (someBool! = True)” lub „if (! SomeBool == true)” lub inne tego rodzaju zwoje, to może być walka, którą warto
wybrać
3
W jaki sposób (someBool == false) jest gorsze niż jeśli (someBool == true)?
FinnNk 18.10.10
5
true=truenie kompiluje się, nie można przypisać do true;-)
fredoverflow 18.10.10
1
I już się przyzwyczaili do if(somebool == false)albo !=, ale zawsze przed fałszem i nieprawdą. Uważam to za zbędne, ale ponieważ standard kodowania nalega, aby if()wyglądało to jak wywołanie funkcji, spacja między parenami pomaga mi je odczytać. Sam w sobie bool to bool, ale if (somePointer)nie leci; Wolę, if (somePointer != NULL)ponieważ wskaźnik nie jest boolem.
dash-tom-bang
5
Chodzi o czytelność, a nie nielogiczność lub (mikro) redundancję
Ronny Brendel,
45

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

GrandmasterB
źródło
5
Cóż, dobrze jest dążyć do perfekcji, ale na pewno są większe ryby do smażenia
TJB
3
Myślę, że mówisz to o każdym problemie, który zasługuje na dyskusję.
Dave Van den Eynde
2
Potencjalnie wskazuje to na znacznie większe problemy. Mała brązowa plama na suficie w garażu może nie wydawać się poważną sprawą, ale może oznaczać poważny wyciek wody.
Josh
42

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.

Guffa
źródło
6
To nie jest odpowiedni argument. Jeśli pracujesz w takim języku, możesz po prostu przenieść prawdę na drugą stronę. Pytanie dotyczy tego, czy w ogóle zawierać prawdę.
Cam
8
@Cam: Brakuje Ci sensu. Logika wsteczna nie sugeruję.
Guffa
15
@Cam - podaje rzeczywisty przykład, kiedy może to stanowić problem. Powiedziałbym, że jest to dość istotne.
ChaosPandion
1
@Guffa Cam ma rację. To nie jest powód, aby przestać używać == (anyType) w blokach if.
Ronny Brendel,
2
@Ronny: Nie, nie może się zdarzyć z żadnym typem (chyba że język faktycznie dopuszcza dowolny typ jako warunek). Instrukcja if (answer = 42) {}po prostu się nie kompiluje, ponieważ wyrażenie nie jest boolem.
Guffa,
21

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
    //...
}
Krzywka
źródło
13
czytelność == GoodThing
Muad'Dib
5
if ((czytelność == GoodThing) == true) ...
JoelFan
1
bool isGoodThing = czytelność? true: (codingStandards? true: (internalizationOfConcept? true: false));
johnc,
17
Zmień nazwę zmiennej actionsAreAllowed.
Graeme Perrow,
9
Pisząc if (x) { ..., już twierdzisz, że xjest to wartość logiczna lub można ją przekształcić w wartość logiczną. To, co nazywacie, jest nieistotne.
Daniel Earwicker,
15

Co z zerowalnymi boolami?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
Steve Wellens
źródło
if (MyFlag.Value)
John
1
Nie wszystkie języki mają zerowalne boole, a wiele z tych, które to robią, zaakceptuje twój drugi konstrukt.
zneak 19.10
1
@johnc: „if (MyFlag.Value)” może nie robić tego, co chcesz, ponieważ może zgłosić wyjątek, jeśli MyFlag ma wartość NULL (co możesz przetestować, sprawdzając MyFlag.HasValue).
Ludovic Chabant,
4
To moje zwierzę domowe wkurza z nullable bools :)
Jarrod Dixon
3
bool? isValid = null; if (isValid ?? false);
skolima
11

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.

Casey
źródło
1
W zależności od języka, niektóreValue niekoniecznie musi odpowiadać prawdzie, nawet jeśli ma wartość prawda. Na przykład, (9 == True)ocenia na false w Pythonie i wyobrażam sobie podobne w C ++.
dash-tom-bang
regiony kodu i wiodące podkreślenia sprawiają, że chcę uderzać ludzi w twarz.
MGOwen 19.10.10
11

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

Scott Fletcher
źródło
7
To nie jest złe. Kod, który czyta się jak prawdziwy tekst, jest znacznie lepszy niż domyślny foo. Zachowaj ten nawyk ze względu na czytelność.
Ronny Brendel,
11

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

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

Zamiast:

 otherBool = !someBool
Marcelo de Aguiar
źródło
To zabawne, musiałem utrzymywać system, w którym te wszystkie były zaśmiecone. Doprowadziło mnie to do szaleństwa.
Tjaart,
8

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.

użytkownik1249
źródło
3
C ++ rzeczywiście ma się notz operatorem, a więc robi C (po to standardowy nagłówek <iso646.h>). Jeśli nie chcą (lub nie mogą) korzystać z tego nagłówka (lub jeśli utkniesz z Java lub C #), proponuję wprowadzenie spacji po wykrzyknikiem: if (! condition). To sprawia, że ​​jest to nieco bardziej widoczne.
Konrad Rudolph
1
Robię Java. notnie jest opcją.
6

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.

rev AShelly
źródło
W rzeczywistości w językach, w których operator przypisania zwraca wartość ... jak C ++ ... if (b == true) {nie jest po prostu redundantny. Jest to również trochę ryzykowne, ponieważ możesz przypadkowo zostać przydzielonym truedo b.
Stephen C,
4
Jest nie tylko zbędny w C ++, jest niebezpieczny. Jeśli piszesz if (b == true), a bnie bool, konwersje typów idą w niewłaściwy sposób. boolJest integralną typ, który jest normalnie promowany do odpowiedniego rodzaju integralnej o wartości 1. Jeśli piszesz, powiedzmy, int b(2); if (b == true)wówczas truestaje się intwartością 1 dla celów porównania, zamiast bbyć zmuszane do typu bool, który dałby właściwego rezultatu.
David Thornley,
@DavidThornley, włącz ostrzeżenia w swoim kompilatorze. Traktowanie ostrzeżeń jako błędów jest lepszą defensywną techniką programowania niż unikaniem ==.
Abyx,
5

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

if(someCondition) {
  return true;
} else {
  return false;
}
Sverre Rabbelier
źródło
2
Chłopcze, ile razy to widziałem. To jest dobry przypadek dla narzędzia takiego jak ReSharper.
Job
Tak - jeśli wynajmujesz bryły, kup ReSharper.
Kirk Broadhurst
4

wolę

if (bVal)

lub

if (!bVal)

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

grokus
źródło
4
Z miłości do wszystkiego, co jest święte, tak długo jak to nie if (!bNotVal) lub if (bNotVal)nawet w pierwszej kolejności. Ugh negatywy w nazwach utrudniają czytanie wszystkiego.
dash-tom-bang
2
Wiedziałem, że deweloper, który chciałby się pochwalić, jest NotConnected; if (isNotConnected == true) ... fuj
johnc
4

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

jego

if (true == someBool) {

}

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

Wyświetlana nazwa
źródło
3

Co powiesz na

if (x == "true")

DLACZEGO TO STRING ?!

atfergs
źródło
Pracuję nad jakimś starszym kodem php i czasami znajduję coś takiego if(preg_match('/title/', implode($_POST))){. PHP, wystarczy powiedzieć, muszę znaleźć lepszą pracę.
Keyo
4
tak, również widzę, czy (x == "1"), ale zwykle dzieje się tak ze złym projektem db.
atfergs
Użyłem podobnych konstrukcji, gdy xpochodziły z danych wejściowych użytkownika (na przykład plik konfiguracyjny lub usługa internetowa). Zazwyczaj jednak dopuszczam inne prawdziwe wartości, więc kończy się to bardziejif x.lower().strip() in ["true", "yes", "on", "1"]
eswald
3

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

Matt Sherman
źródło
3

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.

Ronny Brendel
źródło
3
Mówisz „jeśli bla” nie czyta się jak zdanie ... to znaczy, że twoja zmienna nie ma odpowiedniej nazwy ... co jest z tym nie tak: if (userHasRights) doSomething ()
JoelFan
"w wielu przypadkach". Tak masz rację. Zmiana nazwy również jest w porządku. Dzięki „if (QWidget :: acceptDrops () == true)” nie masz możliwości zmiany nazwy. być może dobrze byłoby nazwać to robiAcceptDrops () ... To jest zbyt kłopotliwe (i niemożliwe jest zachowanie spójności przy użyciu tej reguły pominięcia w dowolnym interfejsie API), więc spójność z innymi „== cokolwiek” -ifs, Zdecydowanie sugeruję, aby go nie pomijać, aby nie wyglądał inaczej, przez co wygląda spójnie.
Ronny Brendel,
3

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 :)

cdkMoose
źródło
2

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.

FinnNk
źródło
3
Ponadto, jeśli jest to zgodne ze standardami kodowania zespołu, naprawdę musisz ponownie ocenić standardy, aby pozbyć się takich drobiazgów.
JohnFx
Zgoda! Na wszelki wypadek ...
FinnNk 18.10.10
2

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.

statichippo
źródło
bool b;inicjuje tylko fałsz, gdy bjest polem. Musisz jawnie zainicjować zmienne lokalne.
Matthew Flaschen
+1 uzgodnione. To samo dotyczy innych języków (skryptowych). Musisz wyrazić się jasno, jeśli chcesz przetestować wartość logiczną truelub po prostu „prawda”. Na przykład tzn. Każdy niepusty ciąg znaków jest brany pod uwagę, == trueale nie === truew niektórych językach.
Martin Wickman
2

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)
{...}
Jared G.
źródło
2

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

Praca
źródło
Pierwszy problem wynika z fałszywej przesłanki IMO przy użyciu okropnych nazw zmiennych. Załóżmy, że X, Y, Z zostały nazwane notExceptButHasX, exceptNotButIsntY, doNotUnlessIsExceptZ? Jak to wpływa na czytelność twojego problemu? Jeśli x, y, z nazwano coś w rodzaju „isEnabled”, „isEffective”, „hasProperty”, wówczas twoja instrukcja staje isEnabled || isEffective || hasPropertysię o wiele bardziej czytelna niż porównywanie z truelub false.
Thomas
1

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.

Huperniketes
źródło
1
Posiadanie SomeBoola w stanie być innym niż PRAWDA / FAŁSZ jest złą praktyką kodowania.
AttackingHobo
@AttackingHobo, to jedna z pułapek polegających na braku typów boolowskich w języku i / lub niestosowaniu klasy w celu zapewnienia dokładnie pożądanego zachowania.
Huperniketes
1

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.

bburbank
źródło
1

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.

Tomas Narros
źródło
1

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!

ingh.am
źródło
0

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ę).

driis
źródło
0

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.

niesamowite
źródło
0

Co powiesz na:

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

Tak, widziałem to.

Dave
źródło