In quale ordine devo fare confronti? [duplicare]

Il secondo metodo che elencherai (costante == variabile) è fatto per essere sicuro e per rendere chiaro l'intento. In questo modo, se vedi:

if(variable = constant) 

Nel codice, sai che era intenzionale e non un errore di battitura.

Detto questo, non ho mai visto:

if(constant == variable)

In qualsiasi libro di testo o sostenuto in qualsiasi guida di stile. Esistono strumenti di analisi statica in grado di rilevare l'assegnazione in condizioni condizionali e generare avvisi o errori.

Se lavori in una lingua o in un ambiente che avvisa o genera un errore su variable = constant , suggerirei di attenersi allo standard variabile a sinistra che già usi.

Tecnicamente, entrambi sono equivalenti. Direi che il primo esprime meglio come tendiamo a pensare ai valori di verità, comunque. Ad esempio, prendendo variable == constant e constant == variable e sostituendoli con alcuni valori:

if (boolResult == True) { ... } // variable == constant 

o

if (True == boolResult) { ... } // constant == variable

Questi sono entrambi confronti validi, ma generalmente non pensiamo in termini di valore costante (True) come la cosa testata. È meno ovvio quando si usano letterali come 34 o "string" , ma penso che il concetto sia ancora valido. In inglese, almeno, esprimiamo questo tipo di affermazione in cui la variabile, la cosa da testare, è l'argomento.

"If The-Weather is Nice, I'll talk a walk"

Certo, questo potrebbe non essere vero per le tutte lingue naturali, e sta diventando un po 'pignolo a discuterne troppo a lungo.

È più importante essere coerenti su come ti avvicini ai controlli condizionali. Questo è vero per la maggior parte degli aspetti della programmazione. Scegli il metodo che ha più senso per te e seguilo.

if (a = 2) viene catturato la prima volta che il programmatore esegue un test con un valore diverso da 2 e nessuno può affermare di programmare "in sicurezza" chi non ha eseguito quel test almeno una volta. In altre parole, aumenta la sicurezza solo se stai già programmando un po 'sconsideratamente, quindi la maggior parte delle persone usa la versione più leggibile. In inglese, è variable == constant . Potrebbe essere diverso in altre lingue o in domini molto specifici, ma in genere la maggior parte delle persone si aspetta di vedere le condizioni scritte in quell'ordine.

Questo approccio è anche noto come "condizioni Yoda" ("se è vera la condizione è"), e il suo scopo è catturare l'errore comune nei linguaggi di tipo C, dove per errore si utilizza un singolo = quando si intende == , causando un incarico. Poiché il valore di ritorno di tale assegnazione è il valore appena assegnato, un tale errore può passare inosservato e apparire solo molto più tardi nel codice, in una posizione apparentemente non correlata e apparentemente casuale. Tali bug sono ovviamente il peggior tipo che si possa avere, e quindi la convenzione "Yoda" inverte gli operandi - una costante non è un lvalue, e accidentalmente mettendo uno sul lato sinistro di un incarico provoca un errore del compilatore, il che è positivo perché significa che l'errore viene visualizzato subito, in modo facile da eseguire il debug.

Tuttavia, la convenzione Yoda ha alcuni lati negativi importanti:

• È a costo di leggibilità. "Se il numero di elementi è 4" è più facile da leggere di "Se 4 è il numero di elementi", e questo vale anche per il codice.
• Si basa esclusivamente sulla convenzione; non c'è nulla che impedisca a un programmatore di dimenticare la convenzione, e tu sei di nuovo al punto di partenza. In altre parole, la convenzione non può essere applicata e quindi non hai ancora garanzie.
• Funziona solo per il confronto con non-lvalue. Se confronti due variabili, entrambi i lati sono lvalue e non stai vincendo nulla.

Allo stesso tempo, i compilatori sono avanzati, in modo tale che ora sono in grado di rilevare quello che probabilmente è un incarico involontario in una condizione - semplicemente, se si usa = in una condizione if , il il compilatore lancia un avvertimento. Questo controllo è facile da automatizzare e applicare: basta attivare i flag del compilatore rilevanti nello script di build per considerarlo un errore fatale. Questo, ovviamente, funziona per qualsiasi tipo di confronto tra uguali, indipendentemente dai lvalue, e non compromette in alcun modo la leggibilità.

È più probabile che tu trovi le convenzioni Yoda usate nei progetti più vecchi, e quando è sul posto, probabilmente è meglio tenerne fede, ma non lo consiglierei di usarlo in nuovi progetti - il vantaggio oggi è praticamente pari a zero, e non vale il sacrificio in termini di leggibilità.