Fare un grosso affare con == vero?

C'è un mio collega che scrive costantemente:

if (someBool == true)

Mi spinge verso il muro! Dovrei farne una grande quantità o lasciarlo cadere?

È solo codice ridondante, non vita o morte. Però....

Se sta accadendo molto, potrebbe essere un problema con come someBoolviene nominato. Un buon nome può fare molto per eliminare la necessità di==true

if(IsSomeCondition)

o

if(hasCondition)

o

if(somethingExists)

per esempio.

Quando vedo someBool == true, non posso fare a meno di pensare che il programmatore non abbia interiorizzato l'idea della valutazione , che è una carenza piuttosto fondamentale.

Tuttavia, la mia prospettiva è distorta perché ho trascorso diverse estati al college insegnando la programmazione ai bambini, che spesso scrivevano espressioni come questa perché sinceramente non avevano padroneggiato l'esercizio mentale della valutazione di un'espressione. Una volta che hanno criticato il concetto, la ridondanza è diventata ovvia.

Per un programmatore professionista altrimenti competente, probabilmente non è così. Probabilmente è solo una cattiva abitudine che hanno sviluppato nei loro primi giorni di programmazione e non hanno mai tremato del tutto. Ma mi spaventerebbe ancora un po 'se fosse la prima cosa che vedo qualcuno fare in un'intervista.

Anche questo mi fa impazzire, ma direi che la ridondanza per loro in modo costruttivo e poi lo faccio cadere anche se non sono d'accordo.

In alternativa, puoi provare questo approccio:
Tu: puoi iniziare a utilizzare la seguente convenzione di codice per valutare i booleani?

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

Loro: perché dovremmo farlo? La seconda metà di tale affermazione è ridondante, valuterebbe sempre come vero.

Tu: George, hai ragione. Sciocco me Andiamo con una versione senza ridondanza quindi. Che ne dite di?

if (someBool) {}

Penso che, se qualcosa di così banale è il tuo problema più grande con i tuoi colleghi, dovresti considerarti piuttosto fortunato.

Dovresti assolutamente fermare questa cattiva abitudine. Delicatamente...

È facile dimenticare di scrivere il doppio segno uguale, trasformando il codice in:

if (someBool = true)

In C # per esempio questo produrrà solo un avvertimento, non un errore. Quindi, a meno che tu non consideri gli avvisi come errori, il codice verrà eseguito, imposta la variabile su true e inserisci sempre la condizione.

Sono d'accordo con te, ma qui interpreto l'avvocato del diavolo:

A seconda della lingua e del nome della variabile, x == true è appropriato:

Considera la seguente situazione in una lingua con tipizzazione statica e coercizione dei tipi per i tipi integrali:

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

Qualcuno che legge questa sezione del codice potrebbe non rendersi immediatamente conto che actionsAllowed è una variabile booleana - potrebbe anche essere un numero intero, che rappresenta il numero di azioni consentite. Quindi aggiungendo == true, diventa chiaro che x è un valore booleano e non un intero che viene forzato in un valore booleano:

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

Che dire boolli nullable?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

In genere, non si vuole fare molto con le convenzioni di codifica a meno che detta convenzione non impedisca in qualche modo al progetto in modo significativo. Ho visto molti argomenti accesi intensificare su cose piccole come le regioni di codice e le sottolineature principali.

Detto questo, non vedo alcun problema con l'aggiunta == truea una dichiarazione condizionale. È un dato di fatto, ho l'abitudine di utilizzare == falseal contrario di un punto esclamativo principale quando testare condizioni negative. Penso che sia più leggibile.

Se esiste una convenzione stabilita, dico seguirla a meno che non ci siano motivi per cambiare. Tuttavia, non vale davvero la pena sollevare un grosso puzzo.

Ack. Sono quel ragazzo. La vergogna, la vergogna. È come ho imparato, ed è come "auto-formattare" nella mia testa. L'unica volta che utilizzo la sintassi preferita di Joel è quando la variabile bool ha un prefisso verbale come "is". Ho bisogno del verbo, sia "is", "can", "did", oppure ho bisogno del == per fornire il verbo "equals". Potrei non rompere mai questa abitudine, quindi capirò se non mi saluti per strada.

mi ricorda il "codice della follia booleana", è come questi

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

Invece di:

 otherBool = !someBool

Personalmente, non mi piace molto il modo di dire "non" nei linguaggi basati su C. Quel piccolo punto esclamativo è troppo facile da trascurare.

Quindi lo scrivo per intero:

if (someCondition == false) {

Dopo averlo letto per un po ', voglio anche la simmetria con

if (someCondition == true) {

Quindi consideralo un artefatto di C usando !invece di not.

Dipende dalla lingua, ma di solito è una cattiva idea ...

In C, non farlo mai . È troppo facile trovare una situazione in cui il valore che si sta testando non è falso (diverso da zero), ma non è uguale al singolo valore definito come "vero".

In Ruby, fallo solo se sei assolutamente certo di voler fallire su tutto tranne che su Boolean true.

In C ++ e in altri linguaggi statici con un tipo bool, è ridondante e può causare errori di programmazione quando si digita in modo errato =invece di ==, oppure errori di promozione come menzionato nei commenti.

Pensi che sia male? Che ne dite di:

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

preferisco

if (bVal)

o

if (!bVal)

anche, ma temo che tirarlo su farà arrabbiare le persone, quindi il mio consiglio è di dimenticarlo. Scusate!

dovresti dirgli che sta sbagliando.

suo

if (true == someBool) {

}

se mai ne dimentica uno = è nei guai nel suo stile di scrittura.

Che ne dite di

if (x == "true")

PERCHÉ È UNA STRINGA ?!

In realtà, se è nullable, sarebbe necessario testare x == true. :)

Scrivo codice così!

Ecco perché:

"if bla == true" si legge come una frase, dove in molti casi "if bla" non lo fa. Sembra sbagliato quando LEGGI il codice reale.

Inoltre il compilatore avverte delle assegnazioni in if block, quindi non c'è davvero alcun pericolo nell'utilizzare == true. (confondendolo con =)

Anche i ragazzi che non scrivono "== true", usano "! ()" Per "== false"? Lo trovo davvero brutto. E se usi "== false", è anche molto coerente usare anche "== true", invece di avere due modi distinti di verificare la verità.

Ricorda che stai lavorando come parte di un team, quindi è necessario elaborare queste cose insieme. "Gioca bene con gli altri" è ancora un tratto importante della personalità anche dopo le elementari :)

Generalmente ometterà '== true', ma non vale nemmeno un minuto per discuterne a meno che tu non l'abbia incluso negli standard di codifica del tuo team.

Mentre sono d'accordo come sviluppatore principalmente C #, non posso dire che sia sempre così. Ad esempio, in Javascript, il === eseguirà la coalescenza di tipo. Quindi supponendo var x = 3 quindi:

if(x) --> true

mentre

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

Immagino che sia diverso da == poiché anche in JS non userei if (x == true) ma solo qualcosa a cui pensare.

Questo tipo di tocchi su un altro punto che è emerso nel mio ufficio:

bool b = false;

In C #, bool b; basterebbe e inizializzare b su falso . Tuttavia, è più esplicito scrivere la riga sopra e comunque dovrebbe essere strappato dal compilatore durante l'ottimizzazione.

Quindi suppongo che il mio punto sia che non è sempre così ovvio ciò che è e non è una buona pratica e molto si riduce alle preferenze e alle caratteristiche / stranezze del linguaggio.

Ah sì, ma cosa succede se la variabile è nullable? (Bool?)

Alcune lingue (C #) richiederanno il cast o il confronto con "true".

bool? isAccepted = true;

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

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

I giovani conoscono le regole, ma i vecchi conoscono le eccezioni;)

In ultimo C#, se hai a che fare con un null-able bool, allora devi:

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

Se il tristato non è un problema, di solito non dovrebbe esserci un motivo per confrontare qualcosa con true/ True. Tuttavia, in Pythone in molte altre lingue come C/C++è possibile eseguire ifun'espressione su non-bool. Queste lingue hanno regole uniche per interpretare numeri interi, puntatori, elenchi, ecc. Come vero o falso. A volte non lo vuoi. Ad esempio, in questo frammento di Python:

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

Qui zdovrebbe essere True, ma z2dovrebbe esserlo False. Ora, un Clojurelinguaggio si avvicina a questo in un altro modo: la andfunzione non necessariamente valuta un bool, ma ifpuò gestirlo.

Indipendentemente dalla lingua, ogni volta che ti trovi a confrontare qualcosa con Trueo False, probabilmente vale la pena commentare.

Una simile codifica mi avrebbe sfregato nel modo sbagliato anche prima. Sebbene l'identificatore di esempio sia denominato "someBool", l'utilizzo involontario di quello stile di codifica su una variabile che non era garantita come booleana potrebbe comportare un comportamento indesiderato. Se il valore di "someBool" non è esattamente "vero" o "falso", il risultato sarà falso.

L'anno scorso ho riscontrato un bug molto sottile causato da un tale stile di programmazione che era difficile da identificare perché gli occhi di uno guardano su tali costrutti. Penseresti: "Come potrebbe essere sbagliato?" Lo stesso vale per espressioni così ben comprese come "(var)" o "(! Var)", che le leggi o le codifichi senza verificarne il comportamento.

Quindi ho introdotto un paio di standard di codifica per ridurre l'esistenza di tali bug nella base di codice e la probabilità che tali bug sottili si insinuino accidentalmente in futuro.

1. Tutte le espressioni devono essere racchiuse tra parentesi secondo il loro intento.
2. Tutti i test booleani devono essere espressi in negativo, come "suchBool! = False".

Ripulendo il codice non conforme al nuovo stile, ho identificato e corretto alcuni altri casi di bug così sottili.

Ho dovuto usarlo tutto il tempo in ActionScript 2 (devo ammettere che ora è una lingua morta), perché:

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)
{
}

Quindi era quasi sempre meglio essere specifici.

Sono d'accordo. È una costruzione ridondante, specialmente in linguaggi tipicamente forti.

Per aggiungere un altro uso improprio di booleani, ho trovato questo tipo di costruzione un sacco di volte in Javascript, (specialmente in alcune funzioni di mostri simili a spaghetti, come in oltre 100 righe):

//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
}

Sembra che a causa della mancanza di una definizione rigorosa del tipo in questo linguaggio, alcuni programmatori preferiscano non dover fare confusione con i false|undefinedvalori.

Ho un collega che avrà un codice come questo:

if(something == true)

E poi, per una sorta di test / debugging, vorrà non chiamare questo blocco, quindi lo cambierà in:

if(something == true && false)

E poi occasionalmente lo cambierà in:

if(false)

La cosa peggiore è che questo tipo di debug mi si è cancellato di tanto in tanto ed è davvero brutto da leggere per gli altri sviluppatori!

Direi che la coerenza è il re in una base di codice. Quindi dovresti usare lo stile, che è usato principalmente nella tua organizzazione. Cerca di rendere il tuo stile preferito parte delle linee guida ufficiali sulla codifica aziendale. Se è già nelle linee guida, basta seguirlo.

(Detto questo, mi infastidirebbe molto, ma probabilmente non abbastanza per farne un grosso problema).

Preferisco non posizionare il extra == vero, ma a volte lo includo accidentalmente e non lo noto. La persona potrebbe non averlo notato e collocato accidentalmente. Rileggo il mio codice e talvolta noto che ho inserito extra == true, quindi rimuovo quello == true. A volte non me ne accorgo e accolgo volentieri qualcuno che mi dice che l'ho posizionato in modo ridondante.

che ne dite di:

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

Sì, l'ho visto.