As declarações de uma única linha se ou afirmações sem práticas erradas?

if (condition) { /* do something */ } else { /* do something */ } if (condition) /* do something */ else /* do something */ 

Foi-me dito que a primeira instância não era uma boa ideia. Não tenho ideia se este é realmente este caso (ou para o segundo); não encurta o valor para digitar? Ou é porque isso só faz uma bagunça?

A melhor prática é escrever código que outros possam ler e atualizar facilmente.

Seu primeiro formulário é questionável porque não segue os formulários que a maioria dos desenvolvedores PHP são usados ​​para:

 if (condition) { // code } else { // code } // ... or ... if (condition) { // code } else { // code } // ... or ... if (condition) { /* short code */ } else { /* short code */ } // ... or ... condition ? /* short code */ : /* short code */; 

Note-se que isso é inteiramente sobre a prática padrão, e não faz sentido. É apenas sobre o que outros desenvolvedores costumam ver.

O seu segundo formulário, mais importante, não é tão bom porque facilita a possibilidade de outro programador cometer esse erro:

 if (condition) // code A else // code B // code C (added by another programmer) 

Neste exemplo, o outro programador adicionou o code C , mas esqueceu de enrolar todo o bloco em chaves. Isso causará problemas. Você pode se defender contra isso simplesmente envolvendo seus blocos if and else em chaves.

Minha preferência se for consistência … então:

 if(...) { statement 1; statement 2; } else { statement 1; statement 2; } 

não é diferente de:

 if(...) { statement 1; } else { statement 1; } 

Então eu sempre usá-los porque é consistente e evita problemas ao esquecer de adicioná-los mais tarde.

No entanto, outras pessoas vão olhar para o meu código e acho que é estúpido colocar o {e}. Eles têm seus motivos, eu tenho o meu … Acontece que eu gosto dos meus motivos mais do que eu gosto do deles 🙂

O código geralmente não legível é uma má prática. A linha única é mais eficiente na sua digitação e poupa números de linha, mas volte a fazê-lo no ano a partir de agora ou enquanto você está procurando por erros e isso será mais difícil.

Na minha opinião, sim, é má prática ter declarações de uma única linha se.

O computador realmente não se importa (tanto quanto eu posso dizer), mas você sempre deve escrever seu código como se ele fosse mantido por um serial killer que sabe onde você mora.

Legível! Facilmente auto discernível.

O problema que eu vi é que os desenvolvedores não reconhecem o {} -less-se quando eles adicionam código a uma das condições. Exemplo:

 //before if(something) statement; //after if(something) statement; addedstatement; 

Obviamente, isso não fará o que eles esperam.

Você já viu um código como esse em C ou C ++?

  /* Warning: bogus C code! */ if (some condition) if (another condition) do_something(fancy); else this_sucks(badluck); 

Ou o recuo é errado, ou o programa é buggy, porque um “else” sempre se aplica ao “if” mais próximo, a menos que você use aparelhos.

(Vamos usar python. Sem suportes, apenas espaços puros puros.: P)

Para todas menos as declarações mais curtas, use as chaves e espaço-as em conformidade. Você quer fazer isso por alguns motivos:

  • É mais difícil cometer um erro sobre a situação.

  • É mais fácil de ler.

  • Em linguagens com instalações de expansão de macro (por exemplo, C, C ++), a falha na inclusão de chaves proporcionará erros de lógica confusos quando uma macro contendo múltiplas declarações for expandida dentro de um if-else não aberto.

Um dos principais benefícios do uso de múltiplas linhas é a facilidade de debugging. Se você tiver uma instrução if else em uma única linha e o depurador lhe disser que a linha x explodiu, é mais difícil determinar qual parte da declaração falhou. Várias linhas também facilitam o passo através do seu código usando um depurador.

São duas linhas de comprimento, então não é realmente uma única linha.

Não há nada de errado com uma única linha, if quando ele torna o código mais fácil de ler.

Por exemplo, algo assim:

 if (last_item) print ", and " else print ", " 

é muito melhor do que

 if (last_iem) { print ", and " } else { print ", " } 

Este é mais estilo de codificação do que qualquer outra coisa. Dito isto, a minha opinião pessoal é que o seu segundo exemplo é potencialmente prejudicial. É fácil o suficiente, acidentalmente, “adicionar uma segunda linha ao bloco” em idiomas onde as chaves são a única maneira de criar blocos. Mas no PHP, onde existe uma syntax alternativa, isso é ainda menos provável para ativar os sinos de aviso necessários:

 if ($_GET["asdf"]==1): /* do something */ else: /* do something */ endif; 

Regra geral: se você colocar seu “fazer algo” em uma linha separada, use aparelhos; Se você não vai usar aparelhos, coloque-o na mesma linha!

Eu vi tantos códigos de terceiros com problemas bobos, que eu prefiro usar aparelhos todo o tempo. Dito isto, nunca me senti bem em

 if(){} else (){} 

Eu uso se () {} na mesma linha quando é uma instrução curta e está sozinho. Se houver outro, use o longo:

 if(checkSomething) { //dosomething } else { //doanotherthing } 

Isso é algo que eu realmente lembro de um exame de emprego um tempo atrás. O código era semelhante ao seguinte:

 if (x == 0) x = 2; else print("x is: %d", x); // debugging! x = 4; 

A maioria das pessoas aqui pode detectar o erro, mas você pode realmente replace em qualquer coisa que você deseja como o “código ruim” que foi inserido. O erro mais sutil ocorre quando você tem uma “versão antiga” de algo comentado, e alguém não responde, e de repente a segunda declaração está fora do bloco.

Basicamente, a menos que seja um pequeno aplicativo de teste para aprender um conceito rápido, eu sempre coloio (e mesmo nos aplicativos de teste que costumo esconder). Não vale a pena dor de cabeça mais tarde, se não o fizer, mesmo em methods de 5 linhas.

Você deve colocar o “se” e “fazer algo” em linhas separadas para tornar seu código mais amigável para depuradores interativos.

Se você colocar o “se” e “fazer algo” na mesma linha, então você não pode definir um ponto de interrupção apenas na linha “fazer algo”.