Perché alcuni programmatori esperti scrivono confronti con il valore prima della variabile?

Question

Possible Duplicates:
How to check for equals? (0 == i) or (i == 0)
Why does one often see “null != variable” instead of “variable != null” in C#?

Ho avuto uno sguardo a un tutorial qua e là, così come un certo codice DirectX e ho notato che molti programmatori esperti C++ scrivere espressioni nel seguente modo:

(<constant> == <variable>) 

piuttosto che ciò che la mia saggezza convenzionale sembra preferire:

(<variable> == <constant>) 

Eg if (NULL == ptr) anziché if (ptr == NULL). Preferisco la seconda alternativa, se non ci sono altri motivi per scegliere la prima, la mia ragione è che la variabile sembra essere la parte "ricevente" dell'espressione.

Ma sospetto che il primo sia utilizzato per evitare di assegnare inavvertitamente il valore della costante alla variabile utilizzando = anziché ==. Sarebbe corretto?

Answer 1

Sì, è corretto. È per rilevare l'errore di battitura di = anziché ==.

Answer 2

Evita che si scrive var = NULL. La scrittura NULL = var produrrà un errore. Quindi hai ragione :-)

Answer 3

sua perché non è possibile assegnare un valore a una costante, quindi se per errore si mette = invece di == il compilatore genera un errore, che vi avverte

Answer 4

Quello usato per essere il caso, sì. Naturalmente, oggigiorno quasi tutti i compilatori mettono in guardia sugli incarichi nelle condizioni if(), quindi il vantaggio è solo lì per le persone che sopprimono regolarmente gli avvisi.

Answer 5

Quella è una giustificazione comune, come è l'argomento che non si vuole spingere la costante off verso l'estrema destra dello schermo con un'espressione prolisso. Quest'ultima argomentazione non mi è mai sembrata particolarmente convincente, e la prima non è realmente valida in questi giorni, dal momento che qualsiasi compilatore che si rispetti emetterà degli avvertimenti (si compila con gli avvertimenti-come-errori, no? :-) .

EDIT: Ho appena incontrato la nuova anteprima di Xcode 4, e basta guardare l'esempio hanno scelto di esemplificare la loro nuova funzione di "Fix-it"!

alt text http://devimages.apple.com/technologies/tools/images/new_autocorrect20100721.jpg

Answer 6

per catturare la differenza tra l'assegnazione e il confronto.

Se vuoi dire:

if (ptr == foo) 

ma digitare

if (ptr = foo) 

se sarà ancora codice valido, dal momento che ptr = foo valuterà a un controllo booleano su ptr dopo che è stato impostato il valore di foo. Ovviamente, tu non vuoi questo.

Tuttavia, ritengo che fa male leggibilità notevolmente, e dato che la maggior parte degli IDE e preprocessore prenderà questo comunque, non usare questo stile.

Answer 7

Come sviluppatore java tendo scrivere espressioni simili:

//primitive check 
    if(constant == variable) 

    //Object check 
    if(constant.equals(variable)) 

Ciò è particolarmente importante per l'oggetto perché l'espressione non fa errore se la variabile è nulla. Se l'espressione era nell'altro ordine, una variabile nulla avrebbe un errore. Mantengo la coerenza e faccio lo stesso ordine per i primitivi.

Answer 8

Controllare la risposta più votate questa domanda ..

https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

Hanno soprannominato questo stile di codifica "Yoda Condizioni".

Answer 9

Questo è stato soprannominato "Condizionale Yoda"!

Vedi qui https://stackoverflow.com/questions/2349378/new-programming-jargon-you-coined

Mi piace molto questo termine perché:

if(Light::On == light) 

si legge come:

"If on is the light"

Come detto già, questo è usato per prevenire l'assegnazione errata. Si potrebbe sostenere che questa pratica è arcaica basata su IDE moderni, ma ritengo comunque che sia una buona pratica.

Answer 10

L'assegnazione di cattura è una delle ragioni principali per cui vengono utilizzate le condizioni Yoda, ma ce ne sono altre: in C++ l'operatore viene richiamato sull'operando LHS. Poiché le costanti sono in genere const (duh) o primitive, ciò limita la possibilità di operazioni non sensoriali. Un esempio è = su un valore letterale primitivo, come il motivo comune indicato (1 = a), ma questo include operator=() const o qualsiasi altro operatore viene utilizzato per i tipi non POD.

Answer 11

Con un linguaggio come VB 6.0 che non non ha assegnazione distinte e operatori di confronto,

a = 2

'compilerà, se si intende un viene assegnato 2 o se si sta confrontando un con 2 Se intendevi confrontare, c'è una probabilità che si verifichi un errore di runtime.

'per l'assegnazione se si scrive sempre

a = 2

' E per l'assegnazione se si scrive sempre

2 = a

'Si elimina la fase di compilazione successo e runtime - Scenario di riferimento.

Ma, questo è solo la punta: il suggerimento visivo è disponibile quando si dispone di un'espressione come

a = b 'di confronto o di assegnazione?

C# presenta: - assegnazione diversa (=) & confronto (==) simboli - comparazioni devono essere avvolti in parentesi.

Allora questo diventa un non-problema.

Answer 12

perché sanno quello che stanno facendo: P

Answer 13

Hai ragione - è di innescare un errore di compilazione, se si digitano "==" come "=", dal momento che un incarico restituirà sempre vero. Anche se questo di solito è facile notare e mettere a punto, di tanto in tanto si trasformerà in un molto difficile da individuare bug, pensare a questo:

#define OK 2 // Or something... 
[...] 
while(status = OK){ 
    // This loop will never end 
    // Even if you change the value of status within it 
    [...] 
} 

Che può essere un brutto bug da trovare, soprattutto se il blocco appartenenza alla dichiarazione incriminata è lunga (immagina di cercare tutti i possibili motivi per cui lo stato è sempre valido).

Se d'altra parte si è utilizzato:

while(OK = status){ 

che getterebbe un errore di compilazione, poiché non è possibile assegnare un valore a una costante.

questa pratica è talvolta indicato come condizioni Yoda, poiché giustappone oggetto e soggetto. Come "se lo stato è OK" vs "se OK è lo stato" e "il cielo è blu" vs "blu è il cielo" - quest'ultimo è qualcosa che Yoda potrebbe dire.