Komentarz do tego pytania: Sprawdzanie, czy metoda zwraca false: przypisać wynik do zmiennej tymczasowej, czy bezpośrednio wywołać metodę w warunkowym? mówi, że powinieneś używać !boolean
zamiast boolean == false
podczas testowania warunków. Dlaczego? Dla mnie boolean == false
jest znacznie bardziej naturalny w języku angielskim i jest bardziej wyraźny. Przepraszam, czy to tylko kwestia stylu, ale zastanawiałem się, czy istnieje jakiś inny powód tego wyboru !boolean
?
59
boolean == true
: to nie ma sensu. Wyrażenia wewnątrzif
instrukcji to po prostu: wyrażenia. Jeśli coś już ocenia wyrażenie boolowskie, dlaczego miałbyś dodać czek, aby zmusić to do oceny?!boolean_variable
tak właśnie robi większość programistów C, zgadzam się.boolean != true
?Odpowiedzi:
Kiedy widzę taki wiersz
if (!lateForMeeting())
, czytam to jako „Jeśli nie spóźnię się na spotkanie” , co jest dość proste do zrozumienia, w przeciwieństwie doif (lateForMeeting() == false)
tego, co przeczytałem jako „Jeśli fakt, że spóźnię się na spotkanie, jest fałszywy „ .Mają one identyczne znaczenie, ale ten pierwszy jest bliżej tego, jak skonstruowane zostanie równoważne zdanie angielskie.
źródło
if not late_for_meeting
:)unless late_for_meeting
done()
. Podwójne negatywy są złe.Pisanie
== false
i== true
jest zbędne. Można go również doprowadzić do arbitralności. Jeśli zaczniesz pisaćWięc czemu nie
A dlaczego nie
Morał tej historii jest taki, że jeśli
condition
jest to wyrażenie boolowskie, to nie trzeba dodawać== false
; po to!
jest operator ;)źródło
== false
NIE jest zbędne, tylko bardziej szczegółowe niż!
. OTOH== true
jest zbędny.(exp1 != exp2)
vs((exp1 == exp2) == false)
. Wprawdzie są to wymyślone scenariusze, ale prawie nigdy nie powinieneś pisać wyraźnych porównań z prawdą lub fałszem. Tak jak powinieneś używać operatora!=
, więc powinieneś używać!
.!
.bool_expression == bool_literal
,== ...
jest ono zbędne. Nie ma znaczenia, czy testujesz na prawdę, czy na fałsz. To tylko zmiana kolejności następnych / alternatywnych bloków. Przykłady Andresa doskonale ilustrują ten punkt. Większość nowoczesnych kompilatorów zoptymalizuje nadmiarowość, ale nadal jest nadmiarowa.W języku C i niektórych podobnych językach porównywanie wyrażeń boolowskich w celu zapewnienia równości
false
lubtrue
niebezpiecznego nawyku.W języku C dowolne wyrażenie skalarne (numeryczne lub wskaźnikowe) może być użyte w kontekście logicznym, na przykład jako warunek
if
instrukcji. Reguła Cif (cond)
jest równoważnaif (cond != 0)
- tzn. Zero jest fałszem, a każda wartość niezerowa jest prawdą. Jeślicond
jest typu wskaźnika,0
jest traktowane jako stała wskaźnika zerowego;if (ptr)
oznaczaif (ptr != NULL)
.To znaczy że
i
nie oznaczają tego samego . Pierwszy jest prawdziwy, jeśli
cond
jest niezerowy; druga jest prawdziwa tylko wtedy, gdy jest równatrue
, która w C (jeśli masz#include <stdbool.h>
) jest po prostu1
.Na przykład
isdigit()
funkcja zadeklarowana w<ctype.h>
zwracaint
wartość,0
jeśli argument jest cyfrą, niezerową, jeśli nie jest. Może powrócić,42
aby wskazać, że warunek jest spełniony. Porównywanie42 == true
zakończy się niepowodzeniem.Zdarza się, że
0
jest to jedyna wartość uważana za fałszywą, więc porównanie równościfalse
zadziała;if (!cond)
iif (cond == false)
rób to samo. Ale jeśli zamierzasz to wykorzystać, musisz pamiętać, że porównywaniefalse
jest w porządku, a porównywanietrue
nie. Co gorsza, w porównaniu dotrue
będzie działać przez większość czasu (na przykład operatory równości i relacyjne zawsze dają albo0
albo1
). Oznacza to, że wszelkie błędy, które wprowadzisz, używając tego nadal mogą być trudne do wyśledzenia. (Nie martw się, pojawią się, gdy tylko zadasz kod ważnemu klientowi).C ++ ma nieco inne reguły; na przykład jego
bool
typ jest nieco ściślej zintegrowany z językiem iif (cond)
konwertuje sięcond
na typbool
. Ale efekt jest (przeważnie) taki sam.Niektóre inne języki mają coś, co można by nazwać lepiej zachowującymi się wartościami logicznymi, na przykład
cond == true
icond == false
(lub jakakolwiek inna składnia się zdarzy) jest bezpieczne. Mimo to każdy język, który widziałem, ma operatoranot
lub!
; jest tam, więc równie dobrze możesz go użyć. Używaniecond == false
zamiast!cond
lubnot cond
, moim zdaniem, nie poprawia czytelności. (Prawdą jest, że!
postać może być trudna do zobaczenia na pierwszy rzut oka; czasem dodaję spację,!
aby tego uniknąć).Często można uniknąć tego problemu i poprawić przejrzystość, zmieniając nieco kod. Na przykład zamiast:
możesz napisać:
Nie zawsze jest to lepsze, ale nie zaszkodzi szukać okazji tam, gdzie jest.
Podsumowanie: W C i C ++ porównania równości
true
ifalse
są niebezpieczne, zbyt szczegółowe i kiepskie. W wielu innych językach takie porównania mogą nie być niebezpieczne, ale wciąż są zbyt szczegółowe i kiepskie.źródło
== true
niebezpieczny. W ten sposób czuje się lepiej.(==True) . f
aby wyjaśnić, że chcemy-> Bool
instancji funkcji powrotu-polimorfuf
. To jest jaśniejsze niżnot . not . f
i mniej niezręczne niż(f :: a -> Bool)
.pred(x)==pred(y)
funkcja zwracająca boolpred
. Alternatywa,pred(x)? pred(y) : !pred(y)
którą zgodzisz się, jest prawie nie do przyjęcia.pred(x)
ipred(y)
używaj tej samej wartości do oznaczenia prawdy, co jest bezpiecznym założeniem w niektórych językach, ale w innych nie. Na przykład w C możesz pisać!!pred(x) == !!pred(y)
.Jeśli
condition == false
rzeczywiście jest to dla ciebie „znacznie bardziej naturalne”, muszę założyć, że nie jesteś native speakerem. W przeciwnym razie nie mogę tego wyjaśnić, ponieważ nikt tak nie mówi:Porównaj to z
To powiedziawszy, zgadzam się, że pojedynczy, smukły
!
znak jest łatwo przeoczony w kodzie. Z tego powodu wolę słowo kluczowe,not
jeśli jest obsługiwane przez język. C ++ na przykład nie pozwala na to, choć wielu programistów nie są tego świadomi.W przypadku języków, które tego wymagają
!
, wstawiam spację między operatorem a operandem. To sprawia, że negacja jest o wiele trudniejsza do przeoczenia:Zauważ, że każdy programista powinien przetłumaczyć to automatycznie , bez namysłu, na „brak warunku” w głowie. Zdobycie tego rodzaju biegłości w odczytywaniu idiomów kodu jest jednym z pierwszych kroków do zostania dobrym programistą.
źródło
Oba są funkcjonalnie identyczne, więc który z nich należy do gustu.
Głównym powodem, którego używam,
== false
jest to, że stwierdziłem, że!
jest zbyt łatwy do przeoczenia, patrząc na kod.Po tym, jak zostałem poważnie ugryziony, przyzwyczaiłem się dawać to do zrozumienia podczas testowania na fałsz.
Gdyby operator został nazwany
not
tak jak w Pascalu, nie sądzę, aby stałoby się to problemem.źródło
== false
zamiast z!
tego samego powodu (aby wyróżnić się). Jednak nie było wymogu używania== true
, więc każda niezerowa wartość nadal działała tak, jak powinna.!
jest prawdopodobnie najbardziej kłopotliwym błędem tego rodzaju, to IMO nie powinno powodować nawyku pisania,==false
ale pisania lepszych testów jednostkowych.Kiedy widzę
var == false
, zawsze zastanawiam się, czyvar
jest to wartość logiczna czy logiczna z więcej niż dwiema wartościami (na przykład z amaybe
oraz a,undefined
a takżetrue
ifalse
, czy coś w rodzaju dziewięciu wartości IEEE 1164 ).źródło
ponieważ czasami możesz pisać
boolean = false
(z oczywistymi błędami) ifalse == boolean
nie wydaje się to naturalne (bez względu na to, jak dobra jest praktyka)źródło
if( INVALID_HANDLE_VALUE == hFile )
unikać takich rzeczy. W ten sposób, jeśli wpadniesz w poślizg i użyjesz jednego znaku równości zamiast dwóch, pojawi się błąd kompilatora. Oczywiście działa to tylko wtedy, gdy lewy wyraz jest stały, ale zaoszczędził mi więcej bólów głowy, niż mogę zliczyć.hFile==INVALID_HANDLE_VALUE
pisma.if (!boolean_variable)
przekłada się naif the condition is not true
.if (boolean == false)
przekłada się naif the condition not false is true
. Ponieważ jest to odwrócona logika, trudniej ją zrozumieć.źródło
isVisible
byłoby lepszym przykładem. Wtedyif (!isVisible)
oznaczałoby jeśli nie widać - co jest prostsze do zrozumienia czymif (isVisible==false)
, co jest odwrotna logika. Mam nadzieję, że teraz jest wyraźniej. A może źle zrozumiałem twój komentarz?Wierzę, że w (dużo) starszych kompilatorach rozdzieliłyby (boolean == false) na 2 przypisania rejestrów i kod porównawczy w języku maszynowym. Pierwszy przykład zostałby podzielony na jedno przypisanie i operator NOT. Pod względem wydajności operacja porównania wymagałaby szeregu cykli zegara, w zależności od wielkości porównywanego rejestru, w porównaniu z odwróceniem bitowym (1 zegar) i byłaby wolniejsza do wykonania.
Biorąc to pod uwagę, uważam, że nowsze kompilatory zlikwidują to, więc powinno być OK, aby wybrać jedno z nich.
źródło
W pracy często mam do czynienia z booleanami, które mogą być zerowe, więc często koduję tę sprawę jako
ponieważ osobiście uważam, że symetria ułatwia czytanie. Zwłaszcza jeśli testowane są również inne booleany.
Nie obchodzi mnie to w ten czy inny sposób.
źródło
value == true
wtedy nie ma powodu, aby sprawdzić, czy nie jest to wartość zerowa. Jeślivalue == null
nigdy nie powinien wywoływać instrukcji if, toif (value)
powinno wystarczyć.if (value)
generuje wyjątek. Byłbym wdzięczny, gdyby ludzie, którzy oddali głos, podali powód.value == true
byłaby wystarczająca.Kiedy testujesz prawdziwy warunek, warto to zrobić
if (condition)
, zwłaszcza gdy zastosujesz konwencję nazewnictwa zmiennych boolowskich zaczynającą się od „is”:if (isOpen)
jest całkowicie jasne, a użycie!= false
byłoby zbędne.Dla C / C ++ / Java / itp. programista, znaczenie „!” operator jest całkowicie zasymilowany do tego stopnia, że automatycznie widzimy „nie” w naszych umysłach. Więc posiadanie
if (!isOpen)
jest tak samo jasne jakif (_NOT_ isOpen)
dla mnie. Ale nie jesteś wystarczająco zaznajomiony, w C / C ++ możesz utworzyć makro#define _NOT_ !
. Ale zaufaj mi, po kilku latach jest to całkowicie niepotrzebne.Poza tym zawsze lepiej jest testować wartości logiczne bez porównywania ich z literałami. Na przykład niebezpieczne jest testowanie,
if (x == true)
ponieważ wartość logiczna jest uważana za prawdę, jeśli nie jest zerowa, a dosłowna prawda ma tylko jedną określoną wartość, więc x może być „prawda” (tj. Niezerowa), a porównanie porównuje wartość fałszywą (ponieważ zawiera 2, a dosłowna prawda to, powiedzmy, 1). Oczywiście nie dotyczy to porównania z fałszem, ale jeśli nie użyjesz go podczas testowania na prawdę, po co używać go podczas testowania na fałsz?źródło
Rozmiar ma znaczenie ;)
W wyrażeniach mieszanych łatwiej jest przeczytać:
I szczególnie dla ruby przykład, gdzie jest duża różnica:
zero nie jest fałszywe, ale także nie jest prawdą.
źródło
Na podstawie mojego doświadczenia i odpowiedzi na moje pytania, z którymi się powiązałeś.
Niektóre osoby wolą używać if (warunek), ponieważ powodem jest to, że jest krótszy do napisania. i dla mnie to ma sens, na przykład (! isValidated ()) Przeczytałem to jako Not Validated. ale dla mnie wszystko opiera się na osobistych preferencjach i zależy od logicznej struktury metody isValidated (), jeśli zwróci true lub false
źródło
Jeśli poprawnie nazwałeś swoją zmienną,
!boolean
jest to bardziej naturalne. Odczytuje jaknot boolean
każdy, kto ma dość programisty, aby czytać kod w myślach.źródło
Dla niektórych ludzi im wcześniej zostanie to określone, tym lepiej.
Dla tych, którzy mają „jeśli! ...” porównuje się szybciej do „jeśli ...”, to muszą przeczytać cały warunek (który może być naprawdę długi, np. (ThisThing = thatThing lub coś = inna rzecz) LUB ( thinga = thingb i thinga = thingd) itd.), aby znaleźć == false na końcu.
Posiadanie! (Właściwie wolę „nie”, gdy pozwala na to język). Natychmiast pojawia się angielskie „nie” dla tego warunku.
Ten problem prowadzi również do rozważenia używania go
until
w językach, które go obsługują, np. Rób „typowe rzeczy”, dopóki coś się nie zakończy. Jak mówią inni, celem jest ekspresja języka naturalnego. Podoba mi się powyższy przykład „słońce świeci”.źródło
Innym powodem jest to, że jeśli pracujesz w bazie kodu, która używa kilku języków, jeśli istnieje jeden idiomatyczny sposób na zrobienie czegoś, co jest bezpieczne we wszystkich językach, całkiem dobrym pomysłem jest zrobienie tego w ten sposób wszędzie, aby stworzyć dobry nawyk i rzadziej się potkną.
Nie mogę wymyślić nigdzie, co
if (!variable)
(lub odpowiedniki, takie jakif not variable
zależnie od twojego języka) nie jest bezpieczne, podczas gdy np.if self.is_ready() == False: ...
Nie jest bezpieczny w Pythonie, jeśliself.is_ready()
powróciNone
, teraz lub w przyszłości, co byłoby całkowicie rozsądnym rozwiązaniem wskazują, że nie był gotowy, ponieważNone
jest tak samo falsey jakFalse
.źródło