Em termos de manutenção, "outro tempo" sem aparelhos intermediários é considerado seguro?

Os else whileaparelhos sem intervenção são considerados "seguros" na manutenção?

Escrever if-elsecódigo sem chaves como abaixo ...

if (blah)
    foo();
else
    bar();

... apresenta um risco porque a falta de chaves facilita muito a alteração inadvertida do significado do código.

No entanto, abaixo também é arriscado?

if (blah)
{
    ...
}
else while (!bloop())
{
    bar();
}

Ou é else whilesem aparelhos intermediários considerado "seguro"?

Isso me lembra este código:

if ( ... ) try {
..
} catch (Exception e) {
..
} else {
...
}

Toda vez que você combina dois tipos de blocos, esquece chaves e não aumenta o recuo, você está criando um código muito difícil de entender e manter.

Talvez seja porque eu aprendi meu ofício (quando) usando o método Jackson Entity Structure Diagram , mas subscrevo a visão de que o único termo correto e não abrigado após um ifou um elseé subsequente if(ou seja, permitindo uma else ifescada)

Qualquer outra coisa (sem trocadilhos) deixa potencial para mal-entendidos e / ou problemas de manutenção. Esse é o aspecto central da ideia do OP ser "inseguro".

Eu também ficaria muito cauteloso ao incluir o while()na mesma linha que o else- preparado ou não. Não me parece certo ... a falta de máscaras de recuo extras é a elsecláusula. E a falta de clareza gera mal-entendidos (veja acima).

Portanto, no exemplo, aconselho / recomendo fortemente (e insisto, na minha equipe):

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

Claro, eu também esperaria ver comentários adequados.

- Editar -

Recentemente, a Apple sofria de uma vulnerabilidade SSL, causada por uma correção de manutenção ruim - que adicionava uma segunda linha a uma única linha sem suporte. Então, vamos colocar na cama a ideia de que linhas simples não-retocadas estão OK?

Sempre fui ensinado a manter tudo entre chaves, recuado e comentado. Eu acredito que é muito mais fácil ler e detectar erros. Pessoalmente, acho que a modularidade é a chave, então eu sempre escreveria o código assim:

    if(blah)
    {
     ....
    }
    else
    {
       while(!bloop()
       {
        bar;
       }
    }

Eu extrairia o método e faria

if ( blah )
{
    ...
}
else
{
   newMethod();
}

Consulte a abordagem "método de extração" explicada no site do catálogo de refatoração :

Você tem um fragmento de código que pode ser agrupado.

Transforme o fragmento em um método cujo nome explica a finalidade do método.

void printOwing() {
    printBanner();

    //print details
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + getOutstanding());
}

                                                                                                        

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails (double outstanding) {
    System.out.println ("name:    " + _name);
    System.out.println ("amount    " + outstanding);
}

Eu consideraria isso um mau hábito de codificação. Às vezes, funciona perfeitamente bem e você não terá problemas ao compilar e executar o código. Outras vezes, pode causar erros graves e você acaba gastando horas corrigindo esse erro.

É sempre recomendável modularizar seu código. Se você precisar colocar um loop while em outra parte, coloque-o em um bloco para que outros, ao trabalhar no seu código, possam entender facilmente a lógica.

if ( blah )
{
    ...
}
else
{
    while ( !bloop() )
    {
        bar();
    }
}

É uma boa prática inserir código em blocos. Isso torna mais simples e fácil entender e depurar também.

Pode ser bom se permanecer simples assim, embora pessoalmente eu não goste e minha preferência seja usar chaves até mesmo para os blocos de código if / else mais simples. É apenas mais arrumado para mim.

No entanto, onde isso fica confuso é quando você aninhar se / else faz um loop em alguns com chaves, outros sem. Um loop While no meio de todo esse espaguete! Eu trabalhei com código tão ruim e é um pesadelo para depurar e entender. Isso segue desde o primeiro ponto; tudo fica bem quando fica simples e você está feliz com isso, mas outros programadores aparecem e adicionam coisas a ele, provavelmente um se mais dentro do loop while. Se está escrito limpo, em primeiro lugar, há menos chance disso acontecer.

O objetivo é esclarecer as coisas para que outros programadores possam ver rapidamente o que é certo e errado. Escreva o código para que o padrão pareça correto e não seja jar.

O outro lado disso é que talvez eu pudesse ver algumas pessoas alegando que, em certos casos, isso parece bem. Se eu tenho o recurso, preciso fazer esse processamento, enquanto espero algo fazer isso. Mesmo assim, para mim ainda não há diferença em aninhar o loop while dentro do bloco else.

Bem, apesar de todos argumentarem sobre o uso de aparelhos e parecem amá-los, na verdade prefiro o contrário. Só uso aparelho quando preciso, porque acho mais legível e conciso sem ele.

if (...)
   foo();
else while(...)
   bar();

... eu realmente acho isso " else while(...)" notavelmente legível! Até parece um inglês simples! Mas acho que as pessoas vão achar isso estranho, porque é incomum dizer o mínimo.

No final, todos nós tendemos a torná-lo à prova de idiotas com suspensórios ... porque, bem, você sabe.

Eu sempre coloco aparelho, só porque você pode adicionar outra linha quando estiver com pressa, recuar, esquecer os aparelhos e coçar a cabeça o que está acontecendo. Eu mantenho o suporte de abertura na mesma linha, mas isso não importa. Nos dois casos, é melhor tê-los.

if(blah) {
    foo();
}
else {
    bar();
}

O que há de tão errado com o aparelho que tantas pessoas estão tentando evitar escrevê-lo?

Que problema else whileresolve exatamente ?

Os aparelhos são baratos e bons, e tornam a intenção do código evidente e clara, ao contrário de inteligente e espirituoso.

Citando a Filosofia Unix:

Regra de clareza: Clareza é melhor que inteligência.

Como a manutenção é tão importante e cara, escreva programas como se a comunicação mais importante que eles fizerem não fosse o computador que os executa, mas os seres humanos que lerão e manterão o código-fonte no futuro (inclusive você).

Não há nada errado com

if (blah)
    foo();
else
    bar();

assim como não há nada de errado com

if (blah) foo(); else bar();

nas circunstâncias certas (suas circunstâncias podem variar, mas esse estilo específico é melhor usado quando você tem muito código repetitivo - a exibição de cada linha é mais importante que o recuo estilístico)

Mas se você escolher um caminho, mantenha-o - a consistência é o rei. Portanto, seu segundo exemplo é muito ruim, como a expressão if tinha colchetes para sua declaração, a declaração while deve estar dentro dos colchetes para a cláusula else, e não fora dela.

além disso, eu já vi esse código antes:

if (x) foo()
{
  bar();
}

e foi escrito pelo próprio nazi do padrão de codificação (que insistia em colchetes para tudo).

Os IDEs modernos podem ser facilmente configurados para reformatar (incluindo remover ou adicionar chaves desnecessárias) e / ou recuperar o código ao salvar um arquivo. Assim, seu exemplo se pareceria automaticamente, por exemplo

if (blah) {
  blub();
} else
  while (!bloop()) {
    bar();
  }

A indentação sempre torna o aninhamento facilmente visível, mesmo sem aparelhos desnecessários. Portanto, se você conseguir aplicar essas configurações de IDE, não vejo riscos.

Pessoalmente, acho o código que omite os chavetas e as quebras de linha muito mais legíveis, pois evita a confusão:

if (blah) blub();
else while (!bloop()) bar();

Mas é claro, muitos desenvolvedores ficam muito felizes em discutir sobre essas coisas para sempre e um dia.