Não “if (0 == value)…” faz mais mal do que bem? [fechadas]

Ah, sim, "condicionais Yoda" ("Se o valor for zero, execute este código, você deve!"). Eu sempre aponto qualquer um que afirme que é "melhor" em ferramentas como lint (1). Este problema em particular foi resolvido desde o final dos anos 70. A maioria das linguagens modernas nem mesmo compila uma expressão como if(x = 10) , pois elas se recusam a coagir o resultado da tarefa a um valor booleano.

Como outros já disseram, certamente não é um problema, mas provoca um pouco de dissonância cognitiva.

É desagradável porque impõe um imposto mental pequeno, mas perceptível.

As pessoas leem da esquerda para a direita praticamente em todas as linguagens de programação (e na maioria das linguagens naturais).

Se eu vejo 123 == x , a maneira como analiso mentalmente é:

• 123 - e daí? informações incompletas.
• == - bem, 123 é 123, por que testar ...
• x - ok, então é com isso que estamos preocupados. Só agora eu tenho o contexto.
• Volte a reconsiderar 123 e por que x é comparado a ele.

Quando vejo a análise x == 123 mental é:

• x - Fornece contexto, eu sei qual é a condição. Eu posso escolher ignorar o resto. Com base no fluxo anterior, tenho uma boa ideia do porquê e do que está por vir (e surpreenda-se se for diferente).
• == - Eu pensei assim.
• 123 - Sim.

A interrupção é pequena (em um exemplo simples), mas eu sempre percebo.

Colocar o valor primeiro pode ser uma boa ideia se você quiser chamar a atenção para ele, por exemplo %código%. Normalmente esta não é a intenção.

Nocivo? Não. Funciona de qualquer forma.

Má Prática? Debate, na melhor das hipóteses. É uma programação defensiva simples.

Vale a pena perder o sono? Nah.

Isso é basicamente flaimbait.

Não, não faz mais mal do que bem. Simples.

Mais palavras?

Argumento do compilador? Erm, ish, talvez - não coloque muita fé no complier para salvá-lo de si mesmo.

"Você não deve esquecer" - bem duh - claro que você não deve estar cansado enquanto eu estou codificando o dia todo Eu tive que usar dois idiomas diferentes e às vezes, apenas às vezes, sendo humano, eu cometo um erro.

Difícil de ler? Você está reclamando que um programador decente deve ter == hardwired (o que faz todo tipo de suposições ruins), mas que o mesmo programador decente não pode ler 0 == valor ??

Não faz mal, tem benefícios potenciais, pergunta boba, deixe os outros fazerem o que quiserem e seguir em frente.

Eu não chamaria isso de dano, mas é desagradável. Então, não, eu não diria isso.

Eu nunca senti que o todo "e se eu esquecer um =?" já teve muito peso. Sim, você pode cometer um erro de digitação, mas todos nós cometemos erros de digitação, parece bobo mudar todo o seu estilo de codificação porque você tem medo de cometer um erro. Por que não fazer todas as suas variáveis & funciona todas em minúsculas sem nenhuma pontuação, porque você pode esquecer de capitalizar algo ou esquecer um sublinhado um dia?

Algumas pessoas usam isso para deixar claro exatamente o que uma condicional está fazendo. Por exemplo:

Caminho 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

Caminho 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

Algumas pessoas acham que o segundo exemplo é mais conciso, ou a inversão de argumentos ilustra o ponto de um teste (condicional) antes do teste em si.

Na verdade, eu não me importo de nenhuma maneira. Eu tenho o meu pet peeves sobre o estilo e o maior deles é a inconsistência. Então, faça da mesma forma, de forma consistente e não me importarei em ler seu código.

Misture até o ponto em que parece que seis pessoas diferentes, com seu próprio estilo distinto, trabalharam de uma vez, eu fico um pouco irritado.

Para mim, é um condicionamento simples. Como alguém que aprendeu (nos anos 90) C e C ++, eu me acostumei a usá-lo e ainda usá-lo, mesmo que as razões sejam esclarecidas.

Uma vez que você esteja "condicionado" a olhar para o lado esquerdo para a "constante", ela se torna uma segunda natureza.

Eu também só o uso para equivalência (ou equivalência negada), não para maior / menor que.

Concordo completamente com a resposta do @ Wonko.

O único caso em que acho útil é onde a parte variável do if é bastante longa e ver os valores torna o código mais fácil de ler. As linguagens pontilhadas do namespace têm os melhores exemplos disso.

Por exemplo, algo em que trabalhei com o single sign-on teve uma situação em que você poderia ter duas sessões simultâneas se um certo tipo de erro acontecesse e fosse recuperado de uma certa maneira, então tenho que adicionar um manipulador dentro de um se isso se parecesse com isso:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

É verdade que neste exemplo existem outras maneiras de fazer isso, mas este seria um caso em que a versão número-primeiro é potencialmente mais legível.

E, no entanto, os erros ocorrem. E às vezes você quer uma atribuição em um operador de loop, onde você poderia verificar a igualdade, ou pelo menos é uma prática padrão para usá-lo.

Eu seguro um pouco. O conselho que eu tenho seguido (possivelmente do Código Completo) é manter o que deve ser o menor valor à esquerda nas comparações. Eu estava discutindo isso com um colega antes e ele achou meio que uma loucura, mas eu me acostumei com isso.

Então eu diria:

if ( 0 <= value )

Mas eu também diria:

if ( value <= 100 )

Igualdade tenderei a verificar com a variável à esquerda, é apenas mais legível.