it-swarm.it

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?

105
JoelFan

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

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

if(IsSomeCondition)

o

if(hasCondition)

o

if(somethingExists)

per esempio.

126
Robert Harvey

Quando vedo someBool == true, Non posso fare a meno di pensare che il programmatore non abbia interiorizzato l'idea di 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 evidente.

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.

71
Tim Goodman

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:
You: 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: Per George, hai ragione. Sciocco me Andiamo con una versione senza ridondanza quindi. Che ne dite di?

if (someBool) {}
58
JohnFx

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

45
GrandmasterB

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.

42
Guffa

Sono d'accordo con te, ma ho intenzione di interpretare l'avvocato del diavolo qui:


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
    //...
}
21
Cam

Che dire boolli nullable?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

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 intensificarsi su cose piccole come le regioni di codice e le sottolineature principali.

Detto questo, non vedo alcun problema con l'aggiunta di == true a un'istruzione condizionale. È un dato di fatto, ho l'abitudine di usare == false al contrario di un punto esclamativo iniziale quando si verificano 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.

11
Casey

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.

11
Scott Fletcher

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

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

Invece di:

 otherBool = !someBool
11

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 ! anziché not.

8
user1249

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

In C, mai fallo. È 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 altri linguaggi statici con un tipo bool, è ridondante e può causare errori di programmazione quando si digita male = invece di == o errori di promozione come menzionato nei commenti.

6
AShelly

Pensi che sia male? Che ne dite di:

if(someCondition) {
  return true;
} else {
  return false;
}
5
Sverre Rabbelier

Preferisco

if (bVal)

o

if (!bVal)

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

4
grokus

dovresti dirgli che sta sbagliando.

suo

if (true == someBool) {

}

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

4
Display Name

Che ne dite di

if (x == "true")

PERCHÉ IS CHE UNA STRINGA ?!

3
atfergs

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

3
Matt Sherman

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

3
Ronny Brendel

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 la scuola elementare :)

3
cdkMoose

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.

2
FinnNk

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. Supponendo quindi var x = 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; sarebbe sufficiente e inizializzerebbe b a false. 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 molti si riducono alle preferenze e alle caratteristiche/stranezze del linguaggio.

2
statichippo

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)
{...}
2
Jared G

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

Negli ultimi C#, se hai a che fare con un null-able bool, quindi 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 Python e in molte altre lingue come C/C++ puoi eseguire un if su un'espressione 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 Python:

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

Qui z dovrebbe essere True, ma z2 dovrebbe essere False. Ora, un linguaggio Clojure si avvicina a questo in un altro modo: la funzione and non necessariamente valuta un bool, ma if può gestirlo.

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

2
Job

Tale 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 tra parentesi in base al 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.

1
Huperniketes

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.

1
bburbank

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 il false|undefined valori.

1
Tomas Narros

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!

1
ingh.am

Direi che la coerenza è il re in una base di codice. Quindi dovresti usare lo stile, ovvero principalmente usato nella tua organizzazione. Prova a 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).

0
driis

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.

0
sange

Il mio collega ha chiamato if a loop. Ho vissuto per raccontarlo.

0

Si può sviluppare questa abitudine quando si fa molta programmazione in WPF. Usa un sacco di bool? (nullable bool) le variabili devono scrivere if (someBool == true) o if (someBool ?? false)

0
Poma

Si spera che tu stia usando un linguaggio sensibile, come VB.NET con Option Strict On, che non consente la coercizione di altri tipi al booleano all'interno di un'istruzione If. Quindi non è necessario aggiungere mai "== true" (o "= True" in VB), poiché il caso di coercizione non può accadere. Se si desidera verificare la presenza di un valore diverso da zero, scrivere in modo esplicito (ad es. "Se x <> 0").

0
o. nate

che ne dite di:

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

Sì, l'ho visto.

0
Dave

È un odore di codice per uno sviluppatore alle prime armi. Devono ancora padroneggiare/interiorizzare la condizione booleana e devono valutare esplicitamente la condizione vera o falsa.

0
Chuck Conway

In JavaScript, preferisco if(bool) quando ho una documentazione sufficiente che spiega cosa si aspetta il metodo ... ma quando valutazione di true può significare che la variabile esiste, è uguale al numero 1 o al valore booleano vero, è più duro.

Digitare con forza in JS significa anche meno flessibilità. Chiamata difficile. Linguaggi fortemente tipizzati, adagiare il martello. Altrimenti, chiedi perché lo fa?

In realtà, c'è la tua risposta: chiedigli perché. Quindi correggilo.

0
Clint

usalo come un'opportunità per insegnargli. ti rispetterà di più se lo fai. non vorresti che qualcuno facesse lo stesso per te?

0
Rush Frisby

La ricerca mostra che il codice con molti esuberi è fortemente correlato agli errori. Ecco un documento interessante sull'argomento (avviso PDF).

0
David Plumpton

Il confronto tra i booleani può effettivamente causare gravi problemi. Di recente mi sono imbattuto in un codice interno che diceva:

if(foo == false && bar == 2) {...}

Ora, questo sembra piuttosto semplice, giusto? Semplificalo e basta:

if(!foo && bar == 2) {...}

Sbagliato. In questo caso, l'ordine delle operazioni impone che il && viene valutato per primo, nel senso che questo valuta davvero a:

if(foo == (false && bar == 2))

conosciuto anche come

if(!foo)

Quella cosa in più che avremmo dovuto controllare, bar == 2, è completamente sparito. Ecco perché non approverò mai e poi mai una revisione del codice che contiene someBool == [true|false].

(Puoi vedere come l'istruzione inversa, == true e ||, causerebbe anche problemi.)

0
tghw

Sì, questo è un tipo di mentalità programmatori. Per tutto il tempo in cui considerano "se la condizione" non ha esistenza senza un'espressione con simboli =, <,> ... Ho visto situazioni in cui le persone realmente lottano come "ritorno alla funzione"

if (RowsAffected> 0) {return true; } else {return false; }

I programmatori devono guardare il loro codice dall'angolo in tempo reale .. :)

0
Krishna Prasad A

Un problema in C è che esiste una tradizione di usare valori diversi da 0 e 1 per i booleani.

typedef enum { WHATEVER = 1 << 4 } MyFlags;
if (flags & WHATEVER) {
}

o anche basandosi sul fatto che -1 sia vero.

Il problema è che stai scrivendo un'API:

struct foo { 
  unsigned int bar : 1;
};

void myapi_foo_set_bar(struct foo *foo, int bar) {
   foo->bar = bar;
}

Qui se la barra non è canonicalizzata a 0 o 1 non si adatterà al campo di bit e si romperà:

myapi_foo_set_bar(foo, flags & WHATEVER); /* broken */

Puoi trovare anche altri modi in cui i bool non canonici si rompono, come confrontarli con TRUE o FALSE come nella domanda!

Ad ogni modo, quello a cui sto arrivando è che spesso ha senso canonizzare un bool:

foo->bar = bar != FALSE;

Questa è una stranezza specifica per C, ovviamente.

0
Havoc P

Sì, è un grosso problema perché il nome del booleano dovrebbe dire che è booleano. Dice se hai questo codice:

bool arrayIsEmpty = array.length == 0;
if (arrayIsEmpty) { ... }

È già facile da leggere, quindi non avrai bisogno di == true, anche per la persona o il programmatore con meno senso della valutazione.

0
tia

Le convenzioni di programmazione non sono necessariamente "giuste" o "sbagliate". Esistono per dare al programma una struttura familiare a coloro che lo leggono, in modo che i possibili errori risaltino più chiaramente - è difficile "vedere" un problema se tutto ti sembra leggermente sbagliato.

L'importante è che le convenzioni siano chiaramente definite e concordate da tutti i partecipanti (anche se l'accordo è come "Accetto di usare questa convenzione mentre lavoro qui" :), altrimenti fa più male che bene.

Naturalmente, il caso particolare del confronto di un valore booleano con il vero è chiaramente sbagliato e va evitato a tutti i costi. ;-)

0
Daniel C. Sobral

Scrivo if (var == false) perché dopo aver scritto var non ho voglia di tornare indietro e scrivere! Dietro. Mi piace anche come == false rende più chiaro.

Tuttavia == true è solo strano. Non so se c'è un motivo per fare un grosso problema. Non lo farei se non spingesse gli altri a usarlo o a renderlo uno standard di codifica.

0
user2528

Puoi provare ad avvicinarti al tuo collega con il seguente esempio:

if ((x == 3) == true) {
    ...
}

Dovrebbe dire che il == true è ridondante e deve essere riscritto come

if (x == 3) {
    ...
}

da x == 3 è già un'espressione booleana.

Ora presentagli il someBool == true esempio, ma leggermente riscritto:

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

Poiché someBool è già un valore booleano, rispetto all'esempio precedente, ora dovrebbe essere chiaro che == true è ridondante anche in questo esempio. Pertanto, dovrebbe essere riscritto come:

if (someBool) {
    ...
}
0
gablin

Divertente perché sostituisco sempre il codice come:

if(foo) {

Con:

if(true == foo) {
if(false == foo) {

Ma ho preso questa abitudine perché la maggior parte delle volte il codice con cui ho lavorato non aveva nomi di variabili chiari.

0
mhitza

Questo potrebbe portare alcuni dei tuoi nicker in un batuffolo.

Abbiamo metodi di estensione per .IsTrue e .IsFalse per il tipo bool.

Quindi scriviamo

if (someBool.IsTrue ())

-o-

if (someBool.IsFalse ())

Sì! E li adoro. Quando leggo il codice diventa semplicemente più ovvio per me.

0
ElGringoGrande