ordem expressão operador relacional

Question

Esta é provavelmente uma pergunta boba, mas a curiosidade ficou o melhor de mim. Tenho visto código que ultimamente parece "inverter" a ordem das expressões para operadores relacionais v.g.:.

if (0 == someVariable)

Ao contrário do que eu normalmente ver / gravação:

if (someVariable == 0)

Para mim, o segundo método parece mais legível e intuitiva, por isso estou querendo saber se há alguma razão eu estou vendo o primeiro método? Logicamente, ambas as declarações avaliar ao mesmo resultado, então é apenas uma questão de preferência pessoal como eles são escritos?

Answer 1

Eu entendo que isso é preferência pessoal. Embora colocando a variável segundo você pode garantir que você não possa atribuir a constante à variável que se usou para desenvolvedores C freqüente preocupação. Este é provavelmente por isso que você está vendo-o em c # como desenvolvedores mudar o idioma.

Answer 2

faz Ordem não importa, no entanto, a primeira implica que é a zero, você está verificando. ditames da Convenção o uso de hte último.

Answer 3

A principal razão em C e C ++ é que é fácil de tipo

if (someVariable = 0) {
    ...
}

que sempre falha e também define someVariable a 0.

Eu pessoalmente prefiro o estilo variável-primeiro porque ele lê mais naturalmente, e só espero que eu não esqueça de uso == não =.

Muitos compiladores C e C ++ irá emitir um aviso se você atribuir uma constante dentro de um if. Java e C # evitar este problema, proibindo expressões não-booleanas nas cláusulas if. Python evita este problema, fazendo atribuições uma afirmação, não uma expressão.

Answer 4

O primeiro método existe como uma maneira de lembrar-se de não fazer atribuições em uma instrução IF, o que poderia ter consequências desastrosas em algumas linguagens (C / C ++). Em C # você só vai ser mordido por isso se você estiver booleans configuração.

código C Potencialmente fatal:

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

Em C / C ++, qualquer variável é suscetível a esse problema de VAR = constante quando você destina VAR == constante. Assim, muitas vezes é o costume para reordenar sua declaração SE para receber um erro de compilação se você flub isso:

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

Em C # apenas booleans são suscetíveis a isso, como apenas expressões booleanas são válidos em uma instrução if.

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

Assim, no mundo do C #, não é necessário adoptar a constante == estilo VAR, a menos que você está confortável com isso.

Answer 5

Além de igualdade eu muitas vezes deparamos com um código como

if (0 > number)

ou

if (NULL != pointer)

onde não há sequer qualquer risco de cometer um erro em C / C ++! É uma daquelas situações em que uma técnica de ensino bem-intencionados se transformou em uma planície mau hábito.

Answer 6

O último formato é uma esquerda-over de C-sintaxe, onde, se você inadvertidamente deixado de fora um dos Iguais-sinais, ele fez uma atribuição, em vez de uma comparação.

No entanto, você pode, naturalmente, não atribuir a um literal numérico, por isso, se você o escreveu como o segundo exemplo, você deseja obter um erro do compilador, e não um bug.

Em C #, no entanto, você não pode inadvertidamente fazer isso, por isso realmente não importa.