"Se (0 == valor) ..." não faz mais mal do que bem? [fechadas]

Essa é uma das coisas que mais odeio quando a vejo no código de outra pessoa. Eu sei o que isso significa e por que algumas pessoas fazem dessa maneira ("e se eu acidentalmente colocar '=' em vez disso?"). Para mim, é muito parecido com quando uma criança desce as escadas contando os passos em voz alta.

Enfim, aqui estão meus argumentos contra:

• Isso interrompe o fluxo natural da leitura do código do programa. Nós, humanos, dizemos "se o valor é zero" e não "se o zero é valor".
• Os compiladores modernos avisam quando você tem uma tarefa em sua condição ou, na verdade, se sua condição consiste apenas nessa tarefa, que, sim, parece suspeita de qualquer maneira
• Você não deve esquecer de colocar double '=' quando estiver comparando valores se for um programador. Você também pode esquecer de colocar "!" ao testar a não igualdade.

Ah, sim, "Condicionais Yoda" ("Se o valor for zero, execute este código, você deve!"). Eu sempre aponto quem afirma que é "melhor" em ferramentas como o lint (1). Esse problema específico foi resolvido desde o final dos anos 70. A maioria das linguagens modernas nem compila uma expressão como if(x = 10), pois se recusa a coagir o resultado da atribuição a um booleano.

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

É desagradável porque impõe uma taxa mental pequena, mas perceptível.

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

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

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

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

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

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

Colocar o valor em primeiro lugar pode ser uma boa ideia, se você quiser chamar a atenção, por exemplo if (LAUNCH_NUKES == cmd). Normalmente, essa não é a intenção.

Prejudicial? Não. Funciona de qualquer maneira.

Má prática? Discutível, na melhor das hipóteses. É uma simples programação defensiva.

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 confie demais no complier para salvá-lo de si mesmo.

"Você não deve esquecer" - bem, duh - não, é claro que não deveria. Enquanto isso, eu estou cansada, eu tenho codificado o dia todo, tive que usar duas línguas diferentes e, às vezes, apenas às vezes, ser humano que eu faço um erro.

O objetivo desse tipo de comportamento é que é defensivo, não existe porque você espera cometer erros mais do que você tem seguro porque espera falhar ... mas se você faz o melhor para ser coberto.

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 o valor 0 == ??

Não faz mal, tem benefícios em potencial, pergunta boba, deixa os outros fazerem se quiserem e seguir em frente.

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

Eu nunca senti que o todo 'e se eu esquecer um =?' realmente realmente teve muito peso. Sim, você pode cometer erros de digitação, mas todos cometemos erros de digitação, parece tolice mudar todo o seu estilo de codificação, porque você tem medo de cometer um erro. Por que não tornar todas as suas variáveis ​​e funções todas minúsculas sem pontuação, porque você pode esquecer de colocar algo em maiúscula ou esquecer um sublinhado um dia?

Algumas pessoas o usam para deixar claro exatamente o que um 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 os argumentos de reversão ilustram o ponto de um teste (condicional) antes do próprio teste.

Na verdade, eu realmente não me importo de nenhuma maneira. Eu tenho minhas preocupações sobre estilo e a maior delas é a inconsistência. Portanto, faça da mesma maneira, de forma consistente, e não me importarei de ler seu código.

Misture até o ponto em que parece que seis pessoas diferentes, com seu próprio estilo distinto, trabalharam ao mesmo tempo, fico um pouco irritado.

Para mim, é um condicionamento simples. Como alguém que aprendeu (nos anos 90) C e C ++, me acostumei a ele e ainda o uso, mesmo que as razões sejam lidas.

Quando você está "condicionado" a procurar a "constante" no lado esquerdo, ela se torna uma segunda natureza.

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

Concordo plenamente com a resposta de @ Wonko.

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

Por exemplo, algo em que trabalhei com o logon único teve uma situação em que você poderia ter duas sessões simultâneas se um certo tipo de erro ocorreu e foi recuperado de uma certa maneira, então eu tenho que adicionar um manipulador para o que estava dentro de um que parecia algo assim:

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

É certo que neste exemplo existem outras maneiras de fazer isso, mas esse 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ê deseja uma atribuição em um operador de loop em que possa verificar a igualdade ou, pelo menos, é uma prática padrão usá-la.

Eu o mantenho um pouco. O conselho que segui (possivelmente do Code Complete) é manter o valor mais baixo à esquerda nas comparações. Eu estava discutindo isso com um colega mais cedo e ele pensou que era meio louco, mas eu me acostumei muito.

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.