Non "se (0 == valore) ..." fa più male che bene? [chiuso]

Ah, sì, "condizionali Yoda" ("Se zero è il valore, esegui questo codice devi!"). Indico sempre chiunque affermi di essere "migliore" con strumenti come Lint (1). Questo particolare problema è stato risolto dalla fine degli anni '70. La maggior parte dei linguaggi moderni non compila nemmeno un'espressione come if(x = 10) , poiché rifiutano di forzare il risultato del compito a un booleano.

Come altri hanno già detto, certamente non è un problema, ma provoca un po 'di dissonanza cognitiva.

È odioso perché impone una tassa mentale piccola ma evidente.

Le persone leggono da sinistra a destra praticamente in tutti i linguaggi di programmazione (e nella maggior parte dei linguaggi naturali).

Se vedo 123 == x , il modo in cui l'analizzo mentalmente è:

• 123 - e allora? informazioni incomplete.
• == - beh, 123 è 123, perché testarlo ...
• x - ok, quindi è quello che ci preoccupa. Solo ora ho il contesto.
• Torna a riconsiderare 123 e perché x viene confrontato con esso.

Quando vedo x == 123 parsing mentale è:

• x - Fornisce un contesto, so di cosa tratta la condizione. Potrei scegliere di ignorare il resto. Sulla base del flusso precedente ho una buona idea del perché e di quello che verrà (e sii sorpreso se è diverso).
• == - L'ho pensato.
• 123 - Yup.

L'interruzione è piccola (in un semplice esempio), ma I sempre la nota.

Mettere il valore per primo potrebbe essere una buona idea se vuoi attirare l'attenzione su di esso, ad es. %codice%. Normalmente questa non è l'intenzione.

nocivo? No. Funziona in entrambi i modi.

Cattiva pratica? Discutibile, nella migliore delle ipotesi È semplice programmazione difensiva.

Vale la pena perdere il sonno? Nah.

Questo è fondamentalmente flaimbait.

No, non fa più male che bene. Semplice.

Altre parole?

Argomento del compilatore? Erm, ish, forse - non fidarti troppo del compilatore per salvarti da te stesso.

"Non dovresti dimenticare" - beh duh - no, naturalmente non dovresti dire nel frattempo sono stanco, ho programmato tutto il giorno che ho dovuto usare due lingue diverse e qualche volta, a volte, essendo umano, faccio un errore.

Il punto di questo tipo di comportamento è che è difensivo, non è lì perché ti aspetti di fare errori più di quanto tu abbia un'assicurazione perché ti aspetti di schiantarti ... ma se fai il suo bello è coperto.

Difficile da leggere? Ti lamenti che un programmatore decente dovrebbe avere == hardwired (che fa tutti i tipi di ipotesi scarse) ma che lo stesso programmatore decente non può leggere 0 == valore ??

Non fa male, ha dei potenziali vantaggi, una domanda sciocca, lascia che gli altri lo facciano se vogliono e passano oltre.

Non lo definirei dannoso, ma è odioso. Quindi no, non lo direi.

Non ho mai pensato che il tutto 'cosa succede se dimentico un =?' mai tenuto davvero molto peso. Sì, puoi fare errori di battitura, ma tutti facciamo errori di battitura, sembra sciocco cambiare l'intero stile di codifica perché hai paura di commettere un errore. Perché non rendere tutte le tue variabili e amp; funziona tutto in minuscolo senza punteggiatura, perché potresti dimenticarti di mettere in maiuscolo qualcosa o dimenticare un trattino di sottolineatura un giorno?

Alcune persone lo usano per chiarire esattamente cosa sta facendo un condizionale. Ad esempio:

Way 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Way 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Alcuni ritengono che il secondo esempio sia più conciso o che gli argomenti di inversione illustrino il punto di un test (condizionale) prima del test stesso.

In tutta l'attualità, non mi dispiace affatto. Ho i miei animaletti a proposito di stile e il più grande è l'incoerenza. Quindi, fallo allo stesso modo, in modo coerente e non mi dispiacerà leggere il tuo codice.

Mescola fino al punto in cui sembra che sei persone diverse con il loro stile distintivo lavorato su di esso in una sola volta, mi arrabbio un po '.

Per me, è un semplice condizionamento. Come qualcuno che ha imparato (negli anni '90) C e C ++, mi ci sono abituato e lo uso ancora, anche se le ragioni sono state apprese.

Una volta che sei "condizionato" a guardare il lato sinistro della "costante", diventa una seconda natura.

Anch'io lo uso solo per equivalenza (o equivalenza negata), non per maggiore / minore di.

Sono completamente d'accordo w / @ la risposta di Wonko.

L'unico caso in cui trovo utile è dove la parte variabile di if è piuttosto lunga e vedere i valori rende il codice più facile da leggere. Le lingue punteggiate dello spazio dei nomi hanno i migliori esempi di questo.

Ad esempio, qualcosa su cui ho lavorato con il single sign-on aveva una situazione in cui si potevano avere due sessioni simultanee se si verificava un certo tipo di errore e si era recuperato in un certo modo, quindi devo aggiungere un gestore per esso che era all'interno di un se quello assomiglia a questo:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

Ammetto che in questo esempio ci sono altri modi per farlo, ma questo sarebbe il caso in cui la prima versione numero è potenzialmente più leggibile.

Eppure gli errori si verificano. E a volte vuoi un incarico in un operatore di loop in cui potresti altrimenti controllare l'uguaglianza, o almeno è prassi normale usarlo.

Resto in qualche modo.Il consiglio che ho seguito (possibilmente dal codice completo) è quello di mantenere quello che dovrebbe essere il valore più basso a sinistra nei confronti. Stavo discutendo di questo con un collega prima e pensava che fosse un po 'folle ma mi sono molto abituato.

Quindi direi:

if ( 0 <= value )

Ma vorrei anche dire:

if ( value <= 100 )

L'uguaglianza tenderò a controllare con la variabile a sinistra, però, è solo più leggibile.