Ordine degli articoli confrontati?

Question

L'ho visto in giro, ma non ho mai sentito una chiara spiegazione del perché ... Questo è davvero per qualsiasi lingua, non solo C # o VB.NET o Perl o altro.

Quando si confrontano due elementi, a volte il segno di spunta " il valore viene messo sul lato sinistro anziché sul lato destro. Logicamente per me, prima elenchi la tua variabile e poi il valore a cui stai confrontando. Ma ho visto il contrario, dove la "costante" è elencato per primo.

Che (se presente) guadagno c'è in questo metodo?

Quindi invece di:

if (myValue > 0)

Ho visto:

if (0 < myValue)

o

if (Object.GimmeAnotherObject() != null)

è sostituito da:

if (null != Object.GimmeAnotherObject())

Qualche idea su questo?

TIA! Kevin

Answer 1

Alcuni sviluppatori mettono la costante a sinistra in questo modo

if(0 = myValue)

Questo perché si otterrà un errore dal compilatore, poiché non è possibile assegnare 0 un valore. Invece, dovrai cambiarlo in

if(0 == myValue)

Questo impedisce un sacco di debug dolorosi lungo la strada, dal momento che digitando

if(myValue = 0)

è perfettamente legale, ma molto probabilmente intendevi

if(myValue == 0)

La prima scelta non è quella che vuoi. Cambierà delicatamente il tuo programma e causerà ogni sorta di mal di testa. Spero che chiarisca!

Answer 2

Non credo che una semplice regola come, ma la costante prima o l'ultima costante non sia una scelta molto intelligente. Credo che il controllo dovrebbe esprimerlo in semantica. Ad esempio, preferisco usare entrambe le versioni in un controllo di intervallo.

if ((low <= value) && (value <= high))
{
    DoStuff(value);
}

Ma concordo con gli esempi che hai citato: vorrei solo l'ultima costante e non vedo nessuna ragione obiettiva per farlo nell'altro modo.

if (object != null)
{
    DoStuff(object);
}

Answer 3

In C ++ entrambi sono validi e compilati

if(x == 1)

e

if(x=1)

ma se lo scrivi in ??questo modo

if(1==x)

e

if(1=x)

quindi l'assegnazione a 1 viene catturata e il codice non verrà compilato.

È considerato " più sicuro " per mettere la variabile const sul lato sinistro.

Una volta che hai l'abitudine di mettere la variabile const a sinistra per l'assegnazione tende a diventare la modalità operativa predefinita, ecco perché la vedi comparire anche nei controlli di uguaglianza

Answer 4

Per .Net, è irrilevante, in quanto il compilatore non ti consente di eseguire un compito in una condizione come:

if(x=1)

perché (come hanno detto tutti gli altri) è una cattiva pratica (perché è facile perdere).

Una volta che non ti devi preoccupare di ciò, è leggermente più leggibile inserire prima la variabile e il valore secondo, ma questa è l'unica differenza: entrambe le parti devono essere valutate.

Answer 5

È una pratica di codifica catturare errori di battitura come '! =' digitato come '=' per esempio.

Se sulla sinistra è presente una COSTANTE, tutti gli operatori di assegnazione verranno catturati dal compilatore poiché non è possibile assegnare a una costante.

Molte lingue (in particolare C ) consentono molta flessibilità nella scrittura del codice. Mentre la costante a sinistra ti sembra insolita, puoi anche programmare compiti e condizioni insieme come,

if (var1 = (var2 & var3)) { /* do something */ }

Questo codice porterà il risultato booleano in var1 e / / fa qualcosa * / se il risultato è vero.

Una pratica di codifica correlata è quella di evitare di scrivere codice laddove le espressioni condizionali hanno compiti al loro interno; sebbene il linguaggio di programmazione consenta tali cose. Non ti imbatti molto in questo codice poiché le assegnazioni all'interno dei condizionali sono insolite, quindi il codice tipico non ha tali cose.

Esiste un buon articolo sulle pratiche di codifica del linguaggio C nell'articolo sito IBM DeveloperWorks che è probabilmente ancora rilevante per le persone che scrivono in quella lingua.