Dentro de um loop for, devo mover a condição de interrupção para o campo de condição, se possível? [fechadas]

Às vezes eu preciso de loops que precisam de uma pausa como esta:

for(int i=0;i<array.length;i++){
    //some other code
    if(condition){
        break;
    }
}

Eu me sinto desconfortável com a escrita

if(condition){
    break;
}

porque consome 3 linhas de código. E descobri que o loop pode ser reescrito como:

                                   ↓
for(int i=0;i<array.length && !condition;i++){
    //some other code
}

Portanto, minha pergunta é: é uma boa prática mover a condição para o campo de condição para reduzir linhas de códigos, se possível?

Esses dois exemplos que você deu não são funcionalmente equivalentes. No original, o teste de condição é realizado após a seção "algum outro código", enquanto na versão modificada, é feito primeiro, no início do corpo do loop.

O código nunca deve ser reescrito com o único objetivo de reduzir o número de linhas. Obviamente, é um bom bônus quando funciona dessa maneira, mas nunca deve ser feito à custa da legibilidade ou correção.

Eu não compro o argumento de que "consome 3 linhas de código" e, portanto, é ruim. Afinal, você pode escrever como:

if (condition) break;

e consuma apenas uma linha.

Se ele ifaparecer na metade do loop, é claro que deve existir como um teste separado. No entanto, se esse teste aparecer no final do bloco, você criou um loop que possui um teste contínuo nas duas extremidades do loop, possivelmente aumentando a complexidade do código. Esteja ciente de que, às vezes, o if (condition)teste só faz sentido após a execução do bloco.

Mas supondo que não seja esse o caso, adotando a outra abordagem:

for(int i=0;i<array.length && !condition;i++){
    //some other code
}

as condições de saída são mantidas juntas, o que pode simplificar as coisas (especialmente se " algum outro código " for longo).

Não há resposta certa aqui, é claro. Portanto, esteja ciente das expressões idiomáticas da linguagem, quais são as convenções de codificação de sua equipe etc.

Esse tipo de pergunta provocou debates quase tanto quanto a programação. Para jogar meu chapéu no ringue, eu iria para a versão com a breakcondição e aqui está o porquê (neste caso específico ):

O forloop está lá apenas para especificar os valores de iteração no loop. Codificar a condição de interrupção dentro da qual apenas atrapalha a lógica IMO.

Ter um separador breakdeixa claro que, durante o processamento normal, os valores são os especificados no forloop e o processamento deve continuar, exceto onde a condição entrar.

Como pano de fundo, comecei a codificar a break, depois coloquei a condição no forloop por anos (sob a direção de um programador excepcional) e depois voltei ao breakestilo porque parecia muito mais limpo (e era o estilo predominante em os vários volumes de código que eu estava consumindo).

É outra daquelas guerras sagradas no final do dia - alguns dizem que você nunca deve sair artificialmente de um loop, caso contrário, não é um loop real. Faça o que achar que é legível (tanto para você quanto para os outros). Se reduzir o pressionamento de teclas é realmente o seu lugar, vá jogar código no fim de semana - cerveja opcional.

forloops são para iteração sobre algo ¹ - eles não são apenas lol-vamos-puxar-algumas-coisas-aleatórias-do-corpo-e-colocá-los-no-loop-cabeçalho - as três expressões têm muito significados específicos:

• O primeiro é para inicializar o iterador . Pode ser um índice, um ponteiro, um objeto de iteração ou qualquer outra coisa - desde que seja usado para iteração .
• O segundo é para verificar se chegamos ao fim.
• O terceiro é para avançar o iterador.

A idéia é separar o tratamento da iteração ( como iterar) da lógica dentro do loop ( o que fazer em cada iteração). Geralmente, muitos idiomas têm um loop for-each que libera você dos detalhes da iteração, mas mesmo que seu idioma não tenha essa construção ou se não puder ser usado no seu cenário - você ainda deve limitar o cabeçalho do loop para manipulação de iteração.

Então, você precisa se perguntar - sua condição é sobre o tratamento da iteração ou sobre a lógica dentro do loop? As chances são de que se trata da lógica dentro do loop - portanto, ele deve ser verificado dentro do loop e não no cabeçalho.

¹ Ao contrário de outros loops, que estão "esperando" que algo aconteça. Um loop for/ foreachdeve ter o conceito de uma "lista" de itens para iterar - mesmo que essa lista seja lenta, infinita ou abstrata.

Eu recomendo usar a versão com if (condition). É mais legível e mais fácil de depurar. Escrever três linhas extras de código não quebrará os dedos, mas facilitará a compreensão da sua próxima pessoa.

Se você estiver repetindo uma coleção em que certos elementos devem ser ignorados, recomendo uma nova opção:

• Filtre sua coleção antes de iterar

Java e C # tornam isso relativamente trivial. Não ficaria surpreso se o C ++ tivesse uma maneira de criar um iterador sofisticado para pular certos elementos que não se aplicam. Mas isso só é realmente uma opção se a sua linguagem de escolha a suportar, e a razão pela qual você está usando breaké porque existem condições para processar ou não um elemento.

Caso contrário, há uma boa razão para tornar sua condição parte do loop for - supondo que a avaliação inicial esteja correta.

• É mais fácil ver quando um loop termina mais cedo

Eu trabalhei no código em que seu loop for leva algumas centenas de linhas com vários condicionais e algumas matemáticas complexas acontecendo lá. Os problemas com os quais você se depara são:

• break comandos escondidos na lógica são difíceis de encontrar e às vezes surpreendentes
• A depuração requer percorrer cada iteração do loop para entender realmente o que está acontecendo
• Muito do código não possui refatorações facilmente reversíveis disponíveis ou testes de unidade para ajudar na equivalência funcional após uma reescrita

Nessa situação, recomendo as seguintes diretrizes em ordem de preferência:

• Filtre a coleção para eliminar a necessidade de um, breakse possível
• Tornar a parte condicional das condições do loop for
• Coloque os condicionais com breakno topo do loop, se possível
• Adicione um comentário de várias linhas chamando a atenção para o intervalo e por que ele está lá

Essas diretrizes estão sempre sujeitas à correção do seu código. Escolha a opção que melhor possa representar a intenção e melhorar a clareza do seu código.

Eu recomendo fortemente adotar a abordagem da menor surpresa, a menos que você obtenha um benefício significativo fazendo o contrário.

As pessoas não leem todas as letras ao ler uma palavra e não lêem todas as palavras ao ler um livro - se são adeptos da leitura, olham os contornos das palavras e frases e deixam o cérebro preencher o resto .

Portanto, é provável que um desenvolvedor ocasional assuma que isso é apenas um padrão para loop e nem sequer veja:

for(int i=0;i<array.length&&!condition;i++)

Se você deseja usar esse estilo de qualquer maneira, recomendo alterar as partes for(int i=0;i<e ;i++)informar ao cérebro do leitor que esse é um padrão para loop.

Outro motivo para seguir com if- breaké que você nem sempre pode usar sua abordagem com a forcondição -. Você precisa usar if- breakquando a condição de interrupção é muito complexa para se esconder dentro de uma forinstrução ou depende de variáveis ​​acessíveis apenas dentro do forloop.

for(int i=0;i<array.length&&!((someWidth.X==17 && y < someWidth.x/2) || (y == someWidth.x/2 && someWidth.x == 18);i++)

Então, se você decidir ir com if- break, estará coberto. Mas se você optar por usar for-conditions, precisará usar uma combinação de if- breake for-conditions. Para ser consistente, você precisará mover as condições para frente e para trás entre as forcondições e o if- breaksempre que as condições mudarem.

Sua transformação está assumindo que tudo o que conditioné avaliado é truequando você entra no loop. Não podemos comentar sobre a correção disso neste caso, porque não está definido.

Tendo conseguido "reduzir linhas de código" aqui, você pode então continuar olhando

for(int i=0;i<array.length;i++){
    // some other code
    if(condition){
        break;
    }
    // further code
}

e aplique a mesma transformação, chegando a

for(int i=0;i<array.length && !condition;i++){
    // some other code
    // further code
}

O que é uma transformação inválida, como você agora faz incondicionalmente further codeonde não fazia anteriormente.

Um esquema de transformação muito mais seguro é extrair some other codee avaliar conditionpara uma função separada

bool evaluate_condition(int i) // This is an horrible name, but I have no context to improve it
{
     // some other code
     return condition;
}

for(int i=0;i<array.length && !evaluate_condition(i);i++){
    // further code
}

TL; DR Faça o que for melhor em sua circunstância específica

Vamos pegar este exemplo:

for ( int i = 1; i < array.length; i++ ) 
{
    if(something) break;
    // perform operations
}

Nesse caso, não queremos que nenhum código do loop for somethingseja executado se for verdadeiro, portanto, mover o teste de somethingpara o campo de condição é razoável.

for ( int i = 1; i < array.length && !something; i++ )

Então, novamente, dependendo de se somethingpode ser definido como trueantes do loop, mas não dentro dele, isso pode oferecer mais clareza:

if(!something)
{
    for ( int i = 1; i < array.length; i++ )
    {...}
}

Agora imagine isso:

for ( int i = 1; i < array.length; i++ ) 
{
    // perform operations
    if(something) break;
    // perform more operations
}

Estamos enviando uma mensagem muito clara lá. Se somethingfor verdadeiro durante o processamento da matriz, abandone toda a operação neste momento. Para mover a verificação para o campo de condição, você precisa:

for ( int i = 1; i < array.length && !something; i++ ) 
{
    // perform operations
    if(!something)
    {
        // perform more operations
    }
}

Indiscutivelmente, a "mensagem" ficou turva, e estamos verificando a condição de falha em dois lugares - e se a condição de falha mudar e esquecermos um desses lugares?

É claro que existem muitas outras formas diferentes que um loop e uma condição poderiam ser, todas com suas próprias nuances.

Escreva o código para que ele leia bem (isso é obviamente um pouco subjetivo) e concisa. Fora de um conjunto draconiano de diretrizes de codificação, todas as "regras" têm exceções. Escreva o que você acha que expressa melhor a tomada de decisão e minimize as chances de erros futuros.

Embora possa ser atraente porque você vê todas as condições no cabeçalho do loop e breakpode ser confuso dentro de blocos grandes, um forloop é um padrão no qual a maioria dos programadores espera loop em algum intervalo.

Especialmente desde que você faz isso, adicionar uma condição de interrupção adicional pode causar confusão e é mais difícil ver se é funcionalmente equivalente.

Geralmente, uma boa alternativa é usar um loop whileou do {} whileque verifica as duas condições, assumindo que sua matriz tenha pelo menos um elemento.

int i=0
do {
    // some other code
    i++; 
} while(i < array.length && condition);

Usando um loop que apenas verifica uma condição e não executa o código no cabeçalho do loop, você deixa muito claro quando a condição é verificada e qual é a condição real e qual é o código com efeitos colaterais.

Isso é ruim, pois o código deve ser lido pelos seres humanos - forloops não-idiomáticos geralmente são confusos de ler, o que significa que os bugs provavelmente estão escondidos aqui, mas o código original pode ter sido possível melhorar, mantendo os dois curto e legível.

Se o que você deseja é encontrar um valor em uma matriz (a amostra de código fornecida é um pouco genérica, mas também pode ser esse padrão), tente explicitamente apenas usar uma função fornecida por uma linguagem de programação especificamente para esse fim. Por exemplo (pseudocódigo, como uma linguagem de programação não foi especificada, as soluções variam dependendo de uma linguagem específica).

array.find(item -> item.valid)

Isso deve reduzir visivelmente a solução, simplificando-a, pois seu código diz especificamente o que você precisa.

Na minha opinião, poucas razões dizem que você não deveria.

1. Isso reduz a legibilidade.
   
2. A saída pode não ser a mesma. No entanto, isso pode ser feito com um do...whileloop (não while), pois a condição é verificada após alguma execução do código.
   

Mas, além disso, considere isso,

for(int i=0;i<array.length;i++){

    // Some other code
    if(condition1){
        break;
    }

    // Some more code
    if(condition1){
        break;
    }

    // Some even more code
}

Agora, você pode realmente alcançá-lo adicionando essas condições a essa forcondição?

Eu acho que remover o breakpode ser uma boa idéia, mas não salvar linhas de código.

A vantagem de escrevê-lo sem breaké que a pós-condição do loop é óbvia e explícita. Quando você termina o loop e executa a próxima linha do programa, sua condição do loop i < array.length && !conditiondeve ter sido falsa. Portanto, iera maior ou igual ao comprimento da matriz ou conditioné verdadeiro.

Na versão com break, há uma pegadinha oculta. A condição do loop diz que o loop termina quando você executa outro código para cada índice de matriz válido, mas na verdade existe uma breakinstrução que poderia terminar o loop antes disso e você não a verá a menos que revise o código do loop muito cuidado. E os analisadores estáticos automatizados, incluindo a otimização de compiladores, também podem ter problemas para deduzir quais são as pós-condições do loop.

Essa foi a razão original pela qual Edgar Dijkstra escreveu “Goto Considerado Prejudicial”. Não era uma questão de estilo: sair de um círculo dificulta a formalidade de raciocinar sobre o estado do programa. Escrevi muitas break;declarações em minha vida e, uma vez adulto, até escrevi um goto(para romper com vários níveis de um loop interno crítico para o desempenho e continuar com outro ramo da árvore de pesquisa). No entanto, tenho muito mais probabilidade de escrever uma returndeclaração condicional a partir de um loop (que nunca executa o código após o loop e, portanto, não pode estragar suas pós-condições) do que a break.

Postscript

De fato, refatorar o código para fornecer o mesmo comportamento pode realmente precisar de mais linhas de código. Sua refatoração pode ser válida para algum outro código específico ou se pudermos provar que conditionisso começará falso. Mas seu exemplo é equivalente no caso geral a:

if ( array.length > 0 ) {
  // Some other code.
}
for ( int i = 1; i < array.length && !condition; i++ ) {
  // Some other code.
}

Se algum outro código não for de uma linha, você poderá movê-lo para uma função para não se repetir e quase refatorar seu loop em uma função recursiva de cauda.

Eu reconheço que esse não foi o ponto principal da sua pergunta e você estava mantendo a simplicidade.

Sim, mas sua sintaxe não é convencional e, portanto, é ruim (tm)

Espero que seu idioma suporte algo como

while(condition) //condition being a condition which if true you want to continue looping
{
    do thing; //your conditionally executed code goes here
    i++; //you can use a counter if you want to reference array items in order of index
}

Se você está preocupado com a fordificuldade de ler uma afirmação excessivamente complexa , essa é definitivamente uma preocupação válida. Perder espaço vertical também é um problema (embora menos crítico).

(Pessoalmente, não gosto da regra de que as ifdeclarações sempre devem ter chaves, o que é em grande parte a causa do espaço vertical desperdiçado aqui. Observe que o problema está desperdiçando espaço vertical. Usar o espaço vertical com linhas significativas não deve ser um problema.)

Uma opção é dividi-lo em várias linhas. Definitivamente, é isso que você deve fazer se estiver usando forinstruções realmente complexas , com várias variáveis ​​e condições. (Este é para mim um melhor uso do espaço vertical, dando ao máximo de linhas possível algo significativo.)

for (
   int i = 0, j = 0;
   i < array.length && !condition;
   i++, j++
) {
   // stuff
}

Uma abordagem melhor pode ser tentar usar uma forma mais declarativa e menos imperativa. Isso variará dependendo do idioma ou talvez você precise escrever suas próprias funções para ativar esse tipo de coisa. Também depende do que conditionrealmente é. Presumivelmente, ele deve ser capaz de mudar de alguma forma, dependendo do que está na matriz.

array
.takeWhile(condition)  // condition can be item => bool or (item, index) => bool
.forEach(doSomething); // doSomething can be item => void or (item, index) => void

Uma coisa que foi esquecida: quando interrompo um loop (não faça todas as iterações possíveis, não importa como implementadas), geralmente é o caso de não apenas querer sair do loop, mas também quero saber por que isso aconteceu . Por exemplo, se eu procurar um item X, não apenas rompo o loop, também quero saber que X foi encontrado e onde está.

Nessa situação, ter uma condição fora do loop é bastante natural. Então eu começo com

bool found = false;
size_t foundIndex;

e no loop vou escrever

if (condition) {
    found = true;
    foundIndex = i;
    break;
}

com o loop for

for (i = 0; i < something && ! found; ++i)

Agora, verificar a condição no loop é bastante natural. A existência de uma instrução "break" depende da existência de processamento adicional no loop que você deseja evitar. Se algum processamento for necessário e outro não, você pode ter algo como

if (! found) { ... }

em algum lugar do seu loop.