operatore relazionale espressione ordine

Question

Questa è probabilmente una domanda stupida, ma la curiosità ha avuto la meglio su di me.Ho visto il codice che ultimamente sembra di "invertire" l'ordine delle espressioni per operatori relazionali, ad esempio:

if (0 == someVariable)

In contrapposizione a ciò che vedo di solito/scrittura:

if (someVariable == 0)

Per me, il secondo metodo sembra più leggibile e intuitivo, quindi mi chiedo se c'è qualche motivo sto vedendo il primo metodo?Logicamente, entrambe le affermazioni restituiscono lo stesso risultato, quindi è solo una questione di preferenze personali come sono scritti?

Answer 1

Capisco che questa è una preferenza personale.Anche se mettendo la variabile secondo si può garantire che non accidentalmente assegnare la costante per la variabile che concearn c sviluppatori.Questo è probabilmente il motivo per vederlo in c# come gli sviluppatori di cambiare lingua.

Answer 2

L'ordine non importa, tuttavia, il primo implica che s zero controlli.La convenzione stabilisce l'uso di hte ultimo.

Answer 3

Il motivo principale in C e C++ è che è facile per tipo

if (someVariable = 0) {
    ...
}

che è sempre un fallimento, e anche imposta someVariable a 0.

Io personalmente preferisco la variabile-primo stile, perché si legge di più, naturalmente, e solo spero di non dimenticare di utilizzare == non =.

Molti di C e compilatori C++ emetterà un avviso se si assegna una costante all'interno di un if.Java e C#, per evitare questo problema, che vieta di non-espressioni booleane if clausole.Python consente di evitare questo problema, rendendo le assegnazioni di un'affermazione, non una espressione.

Answer 4

Il primo metodo esiste un modo per ricordare a te stesso di non fare le assegnazioni in un'istruzione IF, che potrebbe avere disastroso conseguenze in alcuni linguaggi (C/C++).In C# sarà solo ottenere morso da questo se stai impostando i valori booleani.

Potenzialmente fatale codice C:

if (succeeded = TRUE)
{
    // I could be in trouble here if 'succeeded' was FALSE
}

In C/C++, qualsiasi variabile è soggetto a questo problema di VAR = COSTANTE quando hai inteso VAR == COSTANTE.Così, è spesso l'abitudine di riordinare l'istruzione IF per ricevere un errore di compilazione se si flub questo:

if (TRUE = succeeded)
{
    // This will fail to compile, and I'll fix my mistake
}

Solo In C# booleane sono sensibili a questo, come solo le espressioni booleane sono validi in un'istruzione if.

if (myInteger = 9)
{
    // this will fail to compile
}

Così, in C# del mondo non è necessario adottare la COSTANTE == VAR stile, a meno che non sei a tuo agio nel farlo.

Answer 5

In aggiunta a parità mi capita spesso di imbattermi codice come

if (0 > number)

o

if (NULL != pointer)

dove non c'è nemmeno il pericolo di commettere un errore in C/C++!E ' una di quelle situazioni dove le migliori intenzioni per insegnare la tecnica si è trasformata in una pianura cattiva abitudine.

Answer 6

Quest'ultimo è un formato di sinistra-over da C-sintassi, dove, se inavvertitamente lasciato fuori uno di uguale segni, ha un compito, invece di un confronto.

Tuttavia, è possibile, naturalmente, non è possibile assegnare a una letterali numerici, quindi, se hai scritto come secondo esempio, si otterrebbe un errore del compilatore, e non un bug.

In C#, tuttavia, non si può inavvertitamente fare questo, in modo che davvero non importa.