Perché usare! Boolean_variable Over boolean_variable == false

Un commento a questa domanda: Verifica se un metodo restituisce false: assegnare il risultato alla variabile temporanea o mettere la chiamata del metodo direttamente in condizione? dice che dovresti usare !booleaninvece di boolean == falsequando testare le condizioni Perché? Per me boolean == falseè molto più naturale in inglese ed è più esplicito. Mi scuso se questa è solo una questione di stile, ma mi chiedevo se ci fosse qualche altro motivo per questa preferenza di !boolean?

Quando vedo una frase del genere if (!lateForMeeting()), la leggo come "Se non in ritardo per l'incontro" , che è abbastanza semplice da capire, al contrario della if (lateForMeeting() == false)quale avrei letto come "Se il fatto che sono in ritardo per l'incontro è falso " .

Sono identici nel significato, ma il primo è più vicino a come sarebbe costruita la frase inglese equivalente.

Scrivere == falseed == trueè ridondante. Può essere portato anche agli estremi arbitrari. Se inizi a scrivere

if (condition == false) { ... }

Allora perché no

if ((condition == false) == true) { ... }

O perché no

if ((someExp == anotherExp) == true) { ... }

La morale di questa storia è che se conditionè un'espressione booleana, non è necessario aggiungere == false; ecco a cosa !serve l' operatore ;)

In C e in alcuni linguaggi simili, confrontare espressioni booleane per l'uguaglianza falseo trueè un'abitudine pericolosa.

In C qualsiasi espressione scalare (numerica o puntatore) può essere utilizzata in un contesto booleano, ad esempio come condizione di ifun'istruzione. La regola C if (cond)è equivalente a if (cond != 0)- cioè, zero è falso e qualsiasi valore diverso da zero è vero. Se condè di tipo puntatore, 0viene trattato come una costante puntatore null; if (ptr)significa if (ptr != NULL).

Ciò significa che

if (cond)

e

if (cond == true)

non significa la stessa cosa . Il primo è vero se condè diverso da zero; il secondo è vero solo se è uguale a true, che in C (se hai #include <stdbool.h>) è semplicemente 1.

Ad esempio, la isdigit()funzione dichiarata in <ctype.h>restituisce un intvalore, 0se l'argomento è una cifra, diverso da zero se non lo è. Può tornare 42per indicare che la condizione è vera. Il confronto 42 == truefallirà.

Succede che 0è l'unico valore considerato falso, quindi il confronto per l'uguaglianza falsefunzionerà; if (!cond)e if (cond == false)fare la stessa cosa. Ma se ne trarrai vantaggio, devi ricordare che il confronto con falseè ok e il confronto con truenon lo è. Peggio ancora, il confronto con truefunzionerà per la maggior parte del tempo (ad esempio, l'uguaglianza e gli operatori relazionali producono sempre 0o 1). Ciò significa che qualsiasi bug che introduci usando questo potrebbe essere difficile da rintracciare. (Non preoccuparti, verranno visualizzati non appena avrai demo del codice su un client importante.)

C ++ ha regole leggermente diverse; ad esempio, il suo booltipo è un po 'più strettamente integrato nel linguaggio e si if (cond)converte condin tipo bool. Ma l'effetto è (principalmente) lo stesso.

Alcune altre lingue hanno ciò che si potrebbe definire booleani meglio educati, in modo tale che cond == truee cond == false(o qualunque sia la sintassi) è sicuro. Anche così, ogni lingua che ho visto ha un operatore noto !; è lì, quindi potresti anche usarlo. L'utilizzo cond == falsepiuttosto che !condo not condnon migliora, secondo me, la leggibilità. (È vero che il !personaggio può essere difficile da vedere a colpo d'occhio; a volte aggiungo uno spazio dopo !per evitarlo.)

E spesso puoi evitare il problema e migliorare la chiarezza riorganizzando leggermente il codice. Ad esempio, anziché:

if (!cond) {
    do_this();
}
else {
    do_that();
}

potresti scrivere:

if (cond) {
     do_that();
}
else {
    do_this();
}

Non è sempre meglio, ma non fa male cercare opportunità dove si trova.

Riepilogo: in C e C ++, i confronti tra uguaglianza truee stile falsepericoloso, eccessivamente prolisso e scadente. In molte altre lingue, tali confronti potrebbero non essere pericolosi, ma sono ancora troppo prolissi e di scarsa qualità.

I due sono funzionalmente identici, quindi quale usare è una questione di gusti.

La ragione principale che ho usato == falseè che ho scoperto che !è troppo facile trascurare, quando guardando il codice.

Essendo stato morso severamente da questo, ho preso l'abitudine di renderlo molto chiaro quando testavo per falso.

Se l'operatore fosse stato nominato notcome in Pascal, non credo che questo sarebbe diventato un problema.

Se condition == falseè davvero "molto più naturale in inglese" per te, allora devo presumere che tu non sia un madrelingua. Altrimenti non posso spiegarlo, perché nessuno parla così:

Se il sole splende è falso, resto a casa.

Confrontalo con

Se il sole non splende rimango a casa.

Detto questo, concordo sul fatto che il singolo !carattere snello sia facilmente trascurato nel codice. Per questo motivo, preferisco la parola chiave notquando supportata dalla lingua. C ++ per esempio lo consente, sebbene molti programmatori non ne siano consapevoli.

Per le lingue che richiedono !, inserisco uno spazio tra operatore e operando. Questo rende la negazione molto più difficile da trascurare:

if (! condition) { … }

Si noti che ogni programmatore dovrebbe tradurlo automaticamente , senza pensarci due volte, a "non condizionare" nella propria testa. Acquisire questo tipo di fluidità nella lettura di espressioni di codice è tra i primi passi per diventare un buon programmatore.

Quando vedo var == falsemi chiedo sempre se varè booleano o di tipo logico con più di due valori (con, ad esempio, a maybee undefineda nonché truee false, o qualcosa di simile ai nove valori di IEEE 1164 ).

perché a volte potresti scrivere boolean = false(con gli errori ovvi) e false == booleannon sembra naturale (non importa quanto sia buona una pratica)

if (!boolean_variable)si traduce in if the condition is not true.

if (boolean == false)si traduce in if the condition not false is true. Poiché questa è una logica inversa, è più difficile da capire.

In (molto) compilatori più vecchi, credo che si spezzerebbero (booleano == falso) in 2 assegnazioni di registro e un codice di confronto in linguaggio macchina. Il primo esempio sarebbe suddiviso in un compito e un operatore NOT. In termini di prestazioni, l'operazione di confronto richiederebbe un numero di cicli di clock, a seconda della dimensione del registro da confrontare, rispetto a un invertitore bit a bit (1 clock) e sarebbe più lento da eseguire.

Detto questo, credo che i compilatori più recenti eliminino questo, quindi dovrebbe essere OK andare con entrambi.

Al lavoro spesso ho a che fare con booleani che possono essere nulli, quindi spesso codifico questo caso come

if (value != null && value == true){
    //do something
}

perché personalmente sento che la simmetria rende più facile la lettura. Soprattutto se ci sono anche altri booleani in fase di test.

Non mi interessa davvero in un modo o nell'altro.

Quando stai testando la vera condizione, ha senso fare solo if (condition), specialmente quando applichi la convenzione di denominazione delle variabili booleane che iniziano con 'is': if (isOpen)è perfettamente chiaro e l'uso != falsesarebbe ridondante.

Per un C / C ++ / Java / ecc. programmatore, il significato di "!" l'operatore è completamente assimilato, al punto che abbiamo automaticamente "non" nella nostra mente quando lo vediamo. Quindi avere if (!isOpen)è chiaro come if (_NOT_ isOpen)per me. Ma non hai abbastanza familiarità, in C / C ++ puoi creare una macro #define _NOT_ !. Ma fidati di me, dopo qualche anno è completamente inutile.

A parte questo, è sempre preferibile testare valori booleani senza confrontarli con i valori letterali. Ad esempio, è pericoloso testare if (x == true)perché un valore booleano è considerato vero se non è zero e il vero letterale ha solo un valore specifico, quindi x potrebbe essere "vero" (cioè diverso da zero) e comunque il confronto viene valutato come falso (perché contiene 2 e il vero vero è, diciamo, 1.) Naturalmente questo non si applica a un confronto con falso, ma se non lo usi quando esegui il test per true, perché utilizzarlo quando esegui il test per false?

Le dimensioni contano ;)

In espressioni miste è più facile leggere:

boolean1 = false
boolean2 = true

p ! boolean1 and ! boolean2
p boolean1 == false and boolean2 == false

E soprattutto per il rubino un esempio in cui c'è una grande differenza:

boolean = nil
p ! boolean         #-> true
p boolean == false  #-> false

zero non è falso, ma non è neppure vero.

Sulla base della mia esperienza e delle risposte alla mia domanda a cui hai collegato.

Alcune persone preferiscono usare if (condizione), per il motivo è che è più breve da scrivere. e per me ha davvero senso, ad esempio (! isValidated ()) ho letto questo come Non convalidato. ma per me è tutto basato sulle preferenze personali e dipende dalla struttura logica del metodo isValidated (), se restituisce vero o falso

Se hai chiamato correttamente la tua variabile, allora !booleanè più naturale. Legge not booleanchiunque abbia abbastanza programmatore per leggere il codice mentalmente.

Per alcune persone, prima viene espresso un significato, meglio è.

Per quelle persone che hanno "se! ..." si confronta più velocemente con "se ...", quindi devono leggere l'intera condizione (che potrebbe effettivamente essere piuttosto lunga, ad esempio (thisThing = thatThing o qualcosa = l'altra cosa) OPPURE thinga = thingb e thinga = thingd), ecc.) solo per trovare == false alla fine.

Avere il! (In realtà preferisco un non quando la lingua lo consente) subito l'inglese 'non' per questa condizione lì prima.

Questo problema porta anche alla considerazione dell'uso untilin lingue che lo supportano, ad esempio fare "cose ​​comuni" fino al completamento dell'operazione. Come altri dicono, l'obiettivo è l'espressione del linguaggio naturale. Mi piace l'esempio "il sole splende" sopra.

Un altro motivo è che se stai lavorando in una base di codice che utilizza diverse lingue, se c'è un modo idiomatico di fare qualcosa che è sicuro in tutte le lingue, è una buona idea farlo in quel modo ovunque in modo da formare una buona abitudine e hanno meno probabilità di inciampare.

Non riesco a pensare da nessuna parte if (!variable)(o equivalenti come if not variabledipendere dalla tua lingua) non è sicuro, mentre ad es. if self.is_ready() == False: ...Non è sicuro in Python se self.is_ready()ritorna None, ora o in futuro, il che sarebbe una cosa del tutto ragionevole da fare indica che non era pronto poiché Noneè altrettanto falso False.