É uma prática ruim usar interrupção no loop for? [fechadas]

É uma má prática usar breakdeclaração dentro de um forloop ?

Digamos, estou procurando um valor em uma matriz. Compare dentro de um loop for e, quando o valor for encontrado, break;saia do loop for.

Esta é uma prática ruim? Vi a alternativa usada: defina uma variável vFounde defina-a como true quando o valor for encontrado e verifique vFounda forcondição da instrução. Mas é necessário criar uma nova variável apenas para esse fim?

Estou perguntando no contexto de um loop normal C ou C ++.

PS: As diretrizes de codificação MISRA desaconselham o uso de interrupções.

Muitas respostas aqui, mas ainda não vi isso mencionado:

A maioria dos "perigos" associados ao uso breakou continueem um loop for são negados se você criar loops organizados e de fácil leitura. Se o corpo do seu loop abranger vários comprimentos de tela e tiver vários sub-blocos aninhados, sim, você pode facilmente esquecer que algum código não será executado após a interrupção. Se, no entanto, o loop for curto e direto ao ponto, o objetivo da instrução break deve ser óbvio.

Se um loop estiver ficando muito grande, use uma ou mais chamadas de função bem nomeadas no loop. O único motivo real para evitar isso é processar gargalos.

Não, quebrar é a solução correta.

Adicionar uma variável booleana dificulta a leitura do código e adiciona uma fonte potencial de erros.

Você pode encontrar todos os tipos de códigos profissionais com instruções 'break' neles. Faz perfeitamente sentido usá-lo sempre que necessário. No seu caso, essa opção é melhor do que criar uma variável separada apenas com o objetivo de sair do loop.

Usar breaktanto quanto continueem forloop é perfeitamente adequado .

Simplifica o código e melhora sua legibilidade.

Longe das práticas recomendadas, o Python (e outras linguagens?) Estendeu a estrutura do forloop , de modo que parte dela só será executada se o loop não for break .

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

Resultado:

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

Código equivalente sem breake útil else:

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

Não há nada inerentemente errado em usar uma instrução break, mas os loops aninhados podem ficar confusos. Para melhorar a legibilidade, muitas linguagens ( pelo menos Java suporta ) quebram os rótulos, o que melhorará bastante a legibilidade.

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

Eu direi que as instruções de quebra (e retorno) geralmente aumentam a complexidade ciclomática, o que dificulta a comprovação de que o código está fazendo a coisa correta em todos os casos.

Se você estiver pensando em usar uma pausa ao iterar sobre uma sequência para um item em particular, convém reconsiderar a estrutura de dados usada para armazenar seus dados. Usar algo como um Conjunto ou Mapa pode fornecer melhores resultados.

break é uma declaração completamente aceitável de usar (assim como continue , btw). É tudo sobre legibilidade do código - contanto que você não tenha loops complicados demais, tudo bem.

Não é como se eles fossem da mesma liga que goto . :)

Regra geral: se seguir uma regra exigir que você faça algo mais estranho e difícil de ler, quebre a regra e quebre a regra.

No caso de fazer um loop até encontrar algo, você se depara com o problema de distinguir achado versus não encontrado quando sai. Isso é:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

Então, ok, você pode definir um sinalizador ou inicializar um valor "encontrado" para nulo. Mas

Por isso, em geral, prefiro inserir minhas pesquisas em funções:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

Isso também ajuda a organizar o código. Na linha principal, "localizar" se torna uma única declaração e, quando as condições são complexas, elas são escritas apenas uma vez.

Depende do idioma. Enquanto você pode verificar uma variável booleana aqui:

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

não é possível fazer isso ao percorrer uma matriz:

for element in bigList: ...

Enfim, breaktornaria ambos os códigos mais legíveis.

No seu exemplo, você não sabe o número de iterações para o loop for . Por que não usar enquanto laço em vez disso, o que permite que o número de iterações a ser indeterminado no início?

É, por conseguinte, não é necessário o uso de ruptura statemement em geral, como o ciclo pode ser melhor demonstrados como uma enquanto loop.

Eu concordo com outras pessoas que recomendam o uso break. A pergunta conseqüente óbvia é por que alguém recomendaria o contrário? Bem ... quando você usa break, pula o restante do código no bloco e as demais iterações. Às vezes, isso causa bugs, por exemplo:

• um recurso adquirido na parte superior do bloco pode ser liberado na parte inferior (isso é verdade mesmo para blocos dentro de forloops), mas essa etapa de liberação pode ser acidentalmente ignorada quando uma saída "prematura" é causada por uma breakdeclaração (em "moderno" C ++, "RAII" é usado para lidar com isso de uma maneira confiável e protegida contra exceções: basicamente, os destruidores de objetos liberam recursos de maneira confiável, independentemente de como um escopo é encerrado)

• alguém pode alterar o teste condicional na fordeclaração sem perceber que existem outras condições de saída deslocalizadas

• A resposta de ndim observa que algumas pessoas podem evitar breaks para manter um tempo de execução de loop relativamente consistente, mas você estava comparando breakcom o uso de uma variável de controle booleana de saída antecipada onde isso não se aplica

De vez em quando, as pessoas que observam esses erros percebem que podem ser evitadas / atenuadas por essa regra de "sem interrupções" ... na verdade, existe toda uma estratégia relacionada à programação "mais segura" chamada "programação estruturada", onde cada função deve ter um único ponto de entrada e saída também (ou seja, sem ir, sem retorno antecipado). Pode eliminar alguns erros, mas sem dúvida apresenta outros. Por que eles fazem isso?

• eles têm uma estrutura de desenvolvimento que incentiva um estilo particular de programação / código e têm evidências estatísticas de que isso produz um benefício líquido nessa estrutura limitada, ou
• foram influenciados por diretrizes ou experiência de programação dentro de tal estrutura, ou
• eles são apenas idiotas ditatoriais, ou
• qualquer uma das inércias históricas acima (relevante em que as justificativas são mais aplicáveis ​​a C do que em C ++ moderno).

É perfeitamente válido de usar break- como outros já apontaram, não está na mesma liga que goto.

Embora você queira usar a vFoundvariável quando quiser verificar fora do loop se o valor foi encontrado na matriz. Também do ponto de vista da capacidade de manutenção, ter uma bandeira comum sinalizando os critérios de saída pode ser útil.

Fiz algumas análises sobre a base de código em que estou trabalhando (40.000 linhas de JavaScript).

Encontrei apenas 22 breakafirmações, das quais:

• 19 foram usadas dentro de switchinstruções (temos apenas 3 instruções de chave no total!).
• 2 foram usados ​​dentro de forloops - um código que eu imediatamente classifiquei para ser refatorado em funções separadas e substituído por returndeclaração.
• Quanto ao loop breakinterno final while... Corri git blamepara ver quem escreveu essa porcaria!

Então, de acordo com minhas estatísticas: Se breakfor usado fora deswitch , é um cheiro de código.

Eu também procurei por continuedeclarações. Não encontrou nenhum.

Não vejo nenhuma razão para que seja uma prática recomendada, desde que você queira concluir o processamento de STOP nesse momento.

No mundo incorporado, há muito código por aí que usa a seguinte construção:

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

Este é um exemplo muito genérico, muitas coisas estão acontecendo atrás da cortina, interrompendo em particular. Não use isso como código padrão, estou apenas tentando ilustrar um exemplo.

Minha opinião pessoal é que não há nada errado em escrever um loop dessa maneira, desde que sejam tomados os devidos cuidados para evitar que ele permaneça indefinidamente.

Depende do seu caso de uso. Existem aplicativos em que o tempo de execução de um loop for precisa ser constante (por exemplo, para satisfazer algumas restrições de tempo ou para ocultar seus dados internos de ataques baseados em tempo).

Nesses casos, fará sentido definir um sinalizador e somente verificar o valor do sinalizador APÓS todas as foriterações do loop terem sido executadas. Obviamente, todas as iterações de loop for precisam executar código que ainda leva aproximadamente o mesmo tempo.

Se você não se importa com o tempo de execução ... use break;e continue;para facilitar a leitura do código.

Nas regras MISRA 98, usadas na minha empresa em C dev, a declaração de interrupção não deve ser usada ...

Edit: Break é permitido em MISRA '04

Claro, break;é a solução para interromper o loop for ou foreach. Eu usei em php em foreach e for loop e encontrei trabalhando.

Discordo!

Por que você ignoraria a funcionalidade interna de um loop for para criar sua própria? Você não precisa reinventar a roda.

Eu acho que faz mais sentido ter seus cheques no topo do seu loop for, assim

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

ou se você precisar processar a linha primeiro

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

Dessa forma, você pode escrever uma função para executar tudo e criar um código muito mais limpo.

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

Ou, se sua condição for complicada, você também pode mudar esse código!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

"Código profissional", repleto de pausas, não parece realmente um código profissional para mim. Parece codificação lenta;)