¿Es una mala práctica usar break en un bucle for? [cerrado]

¿Es una mala práctica usar una breakdeclaración dentro de un forbucle ?

Digamos, estoy buscando un valor en una matriz. Compare dentro de un bucle for y cuando se encuentre el valor, break;salga del bucle for.

¿Es esta una mala práctica? He visto la alternativa utilizada: definir una variable vFoundy establecerla en verdadero cuando se encuentra el valor y verificar vFoundla forcondición de la declaración. ¿Pero es necesario crear una nueva variable solo para este propósito?

Estoy preguntando en el contexto de un C o C ++ normal para el bucle.

PD: Las pautas de codificación MISRA aconsejan no usar break.

Muchas respuestas aquí, pero aún no he visto esto mencionado:

La mayoría de los "peligros" asociados con el uso breako continueen un bucle for se niegan si escribe bucles ordenados y fáciles de leer. Si el cuerpo de su ciclo abarca varias longitudes de pantalla y tiene múltiples subbloques anidados, sí, podría olvidar fácilmente que parte del código no se ejecutará después del corte. Sin embargo, si el ciclo es corto y va al grano, el propósito de la declaración de ruptura debe ser obvio.

Si un bucle se está volviendo demasiado grande, use una o más llamadas de función bien nombradas dentro del bucle. La única razón real para evitar hacerlo es para procesar cuellos de botella.

No, el descanso es la solución correcta.

Agregar una variable booleana hace que el código sea más difícil de leer y agrega una fuente potencial de errores.

Puede encontrar todo tipo de código profesional con declaraciones 'break' en ellos. Tiene sentido usar esto cuando sea necesario. En su caso, esta opción es mejor que crear una variable separada solo con el propósito de salir del ciclo.

Usar breaktan bien como continueen forbucle está perfectamente bien.

Simplifica el código y mejora su legibilidad.

Lejos de las malas prácticas, Python (¿y otros lenguajes?) Extendió la estructura del forbucle para que parte de ella solo se ejecute si el bucle no lo hace break .

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

Salida:

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

Código equivalente sin breaky que ú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.')

No hay nada intrínsecamente incorrecto con el uso de una instrucción break, pero los bucles anidados pueden ser confusos. Para mejorar la legibilidad, muchos lenguajes ( al menos Java ) admiten romper las etiquetas, lo que mejorará en gran medida la legibilidad.

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;
        }
    }
}

Diré que las declaraciones de ruptura (y retorno) a menudo aumentan la complejidad ciclomática, lo que dificulta probar que el código está haciendo lo correcto en todos los casos.

Si está considerando usar un descanso mientras itera sobre una secuencia para algún elemento en particular, es posible que desee reconsiderar la estructura de datos utilizada para mantener sus datos. Usar algo como un Conjunto o un Mapa puede proporcionar mejores resultados.

break es una declaración completamente aceptable para usar (por lo tanto , continue , por cierto). Se trata de la legibilidad del código, siempre que no tenga bucles demasiado complicados y tal, está bien.

No es que fueran la misma liga que goto . :)

Regla general: si seguir una regla requiere que hagas algo más incómodo y difícil de leer que romper la regla, entonces rompe la regla.

En el caso de bucle hasta que encuentre algo, se encuentra con el problema de distinguir entre encontrado y no encontrado cuando sale. Es decir:

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?

Entonces, está bien, puede establecer un indicador o inicializar un valor "encontrado" como nulo. Pero

Es por eso que en general prefiero insertar mis búsquedas en funciones:

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;
}

Esto también ayuda a ordenar el código. En la línea principal, "buscar" se convierte en una sola declaración, y cuando las condiciones son complejas, solo se escriben una vez.

Depende del idioma. Si bien puede verificar una variable booleana aquí:

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

no es posible hacerlo cuando se desplaza sobre una matriz:

for element in bigList: ...

De todos modos, breakharía que ambos códigos fueran más legibles.

En su ejemplo, no sabe el número de iteraciones para el bucle for . ¿Por qué no usar mientras bucle lugar, lo que permite que el número de iteraciones para ser indeterminada al principio?

Es por lo tanto no es necesario utilizar statemement descanso en general, como el bucle puede ser mejor establece como un tiempo de bucle.

Estoy de acuerdo con otros que recomiendan usar break. La pregunta consecuente obvia es ¿por qué alguien recomendaría lo contrario? Bueno ... cuando usa break, omite el resto del código en el bloque y las iteraciones restantes. A veces esto causa errores, por ejemplo:

• un recurso adquirido en la parte superior del bloque puede liberarse en la parte inferior (esto es cierto incluso para los bloques dentro de los forbucles), pero ese paso de liberación puede omitirse accidentalmente cuando una breakdeclaración provoca una salida "prematura" (en "moderno" C ++, "RAII" se utiliza para manejar esto de una manera confiable y segura: básicamente, los destructores de objetos liberan recursos de manera confiable sin importar cómo se salga de un alcance)

• alguien puede cambiar la prueba condicional en la fordeclaración sin darse cuenta de que hay otras condiciones de salida deslocalizadas

• La respuesta de ndim observa que algunas personas pueden evitar que breaks mantenga un tiempo de ejecución de bucle relativamente constante, pero estaba comparando breakcon el uso de una variable de control booleana de salida temprana donde eso no se cumple

De vez en cuando, las personas que observan tales errores se dan cuenta de que pueden ser prevenidos / mitigados por esta regla de "sin interrupciones" ... de hecho, hay una estrategia relacionada con la programación "más segura" llamada "programación estructurada", donde se supone que cada función tiene un único punto de entrada y salida también (es decir, sin ir a, sin retorno anticipado). Puede eliminar algunos errores, pero sin duda introduce otros. ¿Por qué lo hacen?

• tienen un marco de desarrollo que fomenta un estilo particular de programación / código, y tienen evidencia estadística de que esto produce un beneficio neto en ese marco limitado, o
• han sido influenciados por pautas de programación o experiencia dentro de dicho marco, o
• son solo idiotas dictatoriales, o
• cualquiera de las anteriores + inercia histórica (relevante porque las justificaciones son más aplicables a C que a C ++ moderno).

Es perfectamente válido para usar break, como han señalado otros, no está en la misma liga que goto.

Aunque es posible que desee utilizar la vFoundvariable cuando desee verificar fuera del ciclo si el valor se encontró en la matriz. También desde un punto de vista de mantenibilidad, tener una bandera común que indique los criterios de salida podría ser útil.

Hice un análisis sobre la base de código en la que estoy trabajando actualmente (40,000 líneas de JavaScript).

Encontré solo 22 breakdeclaraciones, de esas:

• 19 se usaron dentro de las switchdeclaraciones (¡solo tenemos 3 declaraciones de cambio en total!).
• 2 se usaron dentro de forbucles, un código que inmediatamente clasifiqué como refactorizado en funciones separadas y reemplazado por una returndeclaración.
• En cuanto al último bucle breakinterno while... ¡Corrí git blamea ver quién escribió esta basura!

Entonces, según mis estadísticas: si breakse usa fuera de switch, es un olor a código.

También busqué continuedeclaraciones. No encontré ninguno.

No veo ninguna razón por la cual sería una mala práctica, siempre que desee completar el procesamiento de STOP en ese momento.

En el mundo incrustado, existe una gran cantidad de código que utiliza la siguiente construcción:

    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 es un ejemplo muy genérico, muchas cosas están sucediendo detrás de la cortina, interrupciones en particular. No use esto como código repetitivo, solo estoy tratando de ilustrar un ejemplo.

Mi opinión personal es que no hay nada de malo en escribir un bucle de esta manera, siempre y cuando se tomen las precauciones adecuadas para evitar permanecer indefinidamente en el bucle.

Depende de su caso de uso. Hay aplicaciones en las que el tiempo de ejecución de un bucle for debe ser constante (por ejemplo, para satisfacer algunas restricciones de tiempo o para ocultar sus datos internos de ataques basados ​​en tiempo).

En esos casos, incluso tendrá sentido establecer un indicador y solo verificar el valor del indicador DESPUÉS de que se forhayan ejecutado todas las iteraciones de bucle. Por supuesto, todas las iteraciones de bucle for necesitan ejecutar código que todavía demora aproximadamente el mismo tiempo.

Si no le importa el tiempo de ejecución ... use break;y continue;para que el código sea más fácil de leer.

En las reglas de MISRA 98, que se usa en mi compañía en C dev, la declaración de interrupción no se usará ...

Editar: Se permite el descanso en MISRA '04

Por supuesto, break;es la solución para detener el bucle for o foreach. Lo usé en php en foreach y para loop y encontré que funcionaba.

¡Estoy en desacuerdo!

¿Por qué ignorarías la funcionalidad incorporada de un bucle for para crear el tuyo propio? No es necesario reinventar la rueda.

Creo que tiene más sentido tener sus cheques en la parte superior de su bucle for así

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

o si necesita procesar la fila primero

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

De esta manera, puede escribir una función para realizar todo y crear un código mucho más limpio.

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

O si su condición es complicada, ¡también puede mover ese código!

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

El "Código profesional" que está plagado de interrupciones en realidad no me parece un código profesional. Suena como una codificación perezosa;)