L'uso del confronto esplicito '== true' è sempre negativo? [duplicare]

10

Di recente ho esaminato molti esempi di codice e continuo a notare l'uso di ...

if( expression == true )
    // do something...

e ...

x = ( expression == true ) ? x : y;

Ho sempre cercato di usare ...

x = ( expression ) ? x : y;

e ...

if( expression )
    // do something...

Dove == true è implicito (e ovvio?)

Questa è solo una mia abitudine e io sono schizzinoso riguardo all'uso esplicito di == true , o è semplicemente una cattiva pratica?

    
posta ocodo 16.11.2011 - 00:03
fonte

4 risposte

17

Di solito dipende dalla lingua (in alcune situazioni puoi trovare problemi relativi al cast booleano implicito).

Se stai utilizzando un linguaggio come Javascript, in alcuni casi puoi avere comportamenti imprevisti (guarda Douglas Google Talk di Crockford - è lì da qualche parte, e una bella chiacchierata da guardare comunque).

Dato che ci sono questi strani casi che possono essere un rompicapo da rintracciare e correggere, ho cercato di essere sempre esplicito nelle mie valutazioni (anche usando === quando si usa un linguaggio che lo supporta ).

Il trucco deve essere coerente in tutto il tuo codice base. Quando inizi a lanciare casi speciali nel mix (cioè "bene, se questo ha senso a me , allora userò implicita coercizione), qualcuno è destinato a confondersi da qualche parte e iniziare a usarlo male (e / o fraintendendolo). La cosa più semplice da fare è attenersi a una sola regola, per me, essere espliciti ha senso.

    
risposta data 16.11.2011 - 00:23
fonte
5

Sì.

Ho intenzione di andare avanti e rispondere con un grande sì, dal momento che non ci sono ancora altre risposte. Ma, sempre aperto a nuovi dati che suggeriscono diversamente.

È un sì perché l'espressione già valuta un booleano. Il test esplicito di quel booleano non aggiunge nulla di valore al programma. Infatti, aumenta l'area di superficie per errore (errori di battitura, cambiamenti futuri, ecc.)

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery

    
risposta data 16.11.2011 - 00:12
fonte
4

Sì e no.

Innanzitutto, per coloro che dicono no alla situazione senza eccezioni, ti sfido a trovare una situazione in cui una convenzione di codifica si adatta a tutti i casi d'uso. Questo non è diverso.

Ora, in una situazione in cui è stata valutata una semplice espressione, non aggiungerei == true al codice. È ampiamente auto esplicativo e so che i miei colleghi capirebbero cosa sta succedendo senza molto però. Inoltre potresti cadere nella gioia del debug che sta scrivendo var = true piuttosto che var == true .

while (flag) {
  // iterate
}

In una situazione in cui hai una funzione all'interno del confronto, a meno che il metodo sia della varietà isSomeCondition() , aggiungerei == true . Secondo me, farlo con un metodo ambiguo rende più chiaro cosa si aspetta che il codice sia. Dopotutto, è facile perdere un ! .

while (largeAmbiguousCheckingMethod(input) == true) {

}

In questa situazione dovresti sapere immediatamente quale sia l'intento, assumendo un metodo ben noto, e non ti imbatti nel problema dell'assegnazione accidentale.

    
risposta data 16.11.2011 - 00:27
fonte
2

I tipi booleani non dovrebbero richiedere test espliciti, mentre le variabili non booleane dovrebbero richiedere test espliciti.

La condizione del test dovrebbe essere considerata come un booleano stesso, il cui risultato è vero o falso. Con questa premessa, il test esplicito di un booleano è ridondante e il test implicito di non booleani è di tipo errato. Inoltre, se lo stile di codifica è coerente, un test implicito serve come buon promemoria al lettore che la variabile è di tipo booleano.

Il codice viene letto molto più spesso di quanto non sia scritto quindi, per favore, sii il più gentile possibile alla prossima persona che legge il tuo codice.

    
risposta data 16.11.2011 - 02:05
fonte

Leggi altre domande sui tag