Isso justifica declarações goto?

Me deparei com essa pergunta um segundo atrás e estou retirando parte do material: existe um nome para a construção 'break n'?

Essa parece ser uma maneira desnecessariamente complexa para as pessoas terem de instruir o programa a interromper um loop for aninhado duas vezes:

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

Eu sei que os livros didáticos gostam de dizer que as declarações goto são o diabo, e eu não gosto muito delas, mas isso justifica uma exceção à regra?

Estou procurando respostas que lidem com n-aninhados para loops.

NOTA: Se você responder sim, não ou em algum lugar, respostas completamente fechadas não são bem-vindas. Especialmente se a resposta for não, forneça uma boa razão legítima (que não está muito longe dos regulamentos do Stack Exchange).

A aparente necessidade de uma declaração de aceitação surge da escolha de expressões condicionais ruins para os loops .

Você declara que deseja que o loop externo continue por mais tempo i < 10e o mais interno continue por tanto tempo j > 0.

Mas, na realidade, não era isso que você queria , você simplesmente não disse aos loops a condição real que queria que eles avaliassem, então você quer resolvê-lo usando break ou goto.

Se você disser aos loops suas verdadeiras intenções, para começar , não há necessidade de pausas ou ir.

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

Nesse caso, você pode refatorar o código em uma rotina separada e depois apenas returnno loop interno. Isso negaria a necessidade de romper o loop externo:

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

Não, não acho que gotoseja necessário. Se você escrever assim:

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

Tendo &&!brokenem ambos os loops, você pode sair dos dois loops quando i==j.

Para mim, essa abordagem é preferível. As condições de loop são extremamente claros: i<10 && !broken.

Uma versão de trabalho pode ser vista aqui: http://rextester.com/KFMH48414

Código:

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

Resultado:

o loop quebra quando i == j == 1
2
0 0

A resposta curta é "depende". Defendo a legibilidade e a compreensão do seu código. O caminho para o goto pode ser mais legível do que ajustar a condição ou vice-versa. Você também pode levar em consideração o princípio menos surpreendente, a diretriz usada na loja / projeto e a consistência da base de código. Por exemplo, ir para o switch ou para tratamento de erros é uma prática comum na base de código do kernel do Linux. Observe também que alguns programadores podem ter problemas para ler seu código (ou criados com o mantra "goto is evil", ou simplesmente não são aprendidos porque o professor pensa assim) e alguns deles podem até "julgá-lo".

De um modo geral, um ir além na mesma função geralmente é aceitável, especialmente se o salto não for muito longo. Seu caso de uso de deixar um loop aninhado é um exemplo conhecido de "não é tão mau".

No seu caso, goto é uma melhoria suficiente que parece tentadora, mas não é tanto uma melhoria que vale a pena quebrar a regra contra usá-los em sua base de código.

Pense no seu futuro revisor: ele / ela terá que pensar: "Essa pessoa é uma má codificadora ou é de fato um caso em que o goto valeu a pena? Deixe-me levar 5 minutos para decidir isso por conta própria ou pesquisar no Internet." Por que diabos você faria isso com seu futuro codificador quando não pode usar o goto inteiramente?

Em geral, essa mentalidade se aplica a todo código "ruim" e até o define: se funciona agora e é bom nesse caso, mas cria um esforço para verificar se está correto, o que nesta época um goto sempre fará, então não faça.

Dito isto, sim, você produziu um dos casos um pouco mais espinhosos. Você pode:

• use estruturas de controle mais complexas, como um sinalizador booleano, para interromper os dois loops
• coloque seu loop interno dentro de sua própria rotina (provavelmente ideal)
• coloque os dois loops em uma rotina e retorne em vez de quebrar

É muito difícil para mim criar um caso em que um loop duplo não seja tão coeso que não deva ser sua própria rotina.

A propósito, a melhor discussão sobre isso que eu vi é Code Complete, de Steve McConnell . Se você gosta de pensar criticamente nesses problemas, recomendo fortemente a leitura, mesmo de capa a capa, apesar de sua imensidão.

TLD; DR: Não em específico, sim em geral

Para o exemplo específico que você usou, eu diria não pelas mesmas razões que muitos outros apontaram. Você pode facilmente refatorar o código em um formato equivalente, o que elimina a necessidade de goto.

Em geral, a proscrição contra gotoé uma generalidade baseada na natureza compreendida gotoe no custo de usá-la. Parte da engenharia de software é tomar decisões de implementação. A justificação dessas decisões ocorre ponderando o custo em relação aos benefícios e sempre que os benefícios superam o custo, a implementação é justificada. A controvérsia surge devido a diferentes avaliações, tanto de custo quanto de benefício.

O ponto é que sempre haverá exceções em que a gotoé justificada, mas apenas para algumas por causa de diferentes avaliações. A pena é que muitos engenheiros simplesmente excluam as técnicas por ignorância intencional, porque as leem na internet em vez de dedicar algum tempo para entender o porquê.

Eu não acho que este caso justifique uma exceção, pois isso pode ser escrito como:

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}