language agnostic - Continuar considerado dañino?
Usar continuar al principio de un ciclo para evitar iteraciones sobre elementos innecesarios no es dañino y puede ser muy útil, pero usarlo en medio de ifs y ells anidados puede convertir el código del bucle en un laberinto complejo, para comprenderlo y validarlo.
Creo que su evitación de uso también es el resultado de un malentendido semántico. Las personas que nunca ven / escriben la palabra clave ''continuar'' en su código, al ver un código con continuar pueden interpretarlo como "la continuación del flujo natural". Si en vez de continuar tuviéramos el siguiente , por ejemplo, creo que más personas apreciarían esta valiosa característica del cursor.
¡Creo que debería haber más uso de continuar!
Demasiado a menudo me encuentro con un código como:
for (...)
{
if (!cond1)
{
if (!cond2)
{
... highly indented lines ...
}
}
}
en lugar de
for (...)
{
if (cond1 || cond2)
{
continue;
}
...
}
¡Úselo para hacer que el código sea más legible!
¿ continue más dañino que, por ejemplo, break ?
En todo caso, en la mayoría de los casos en que la encuentro / uso, me parece que hace que el código sea más claro y menos espagueti.
Continuar es una función realmente útil en la mayoría de los lenguajes, ya que permite omitir bloques de código para ciertas condiciones.
Una alternativa sería usar variables booleanas en sentencias if, pero estas deberían reiniciarse después de cada uso.
Continuar me parece mal. romper te saca de allí, pero continuar parece ser espagueti.
Por otro lado, puedes emular continuar con el corte (al menos en Java).
for (String str : strs) contLp: {
...
continue contLp;
...
}
continuar puede ser útil en algunas circunstancias, pero todavía me parece sucio.
for (char c : cs) {
final int i;
if (''0'' <= c && c <= ''9'') {
i = c - ''0'';
} else if (''a'' <= c && c <= ''z'') {
i = c - ''a'' + 10;
} else {
continue;
}
... use i ...
}
Creo que el argumento final en contra de continuar es que hace que sea más difícil PROBAR que el código sea correcto. Esto se prueba en el sentido matemático. Pero probablemente no le importe porque nadie tiene los recursos para ''probar'' un programa de computadora que es significativamente complejo.
Ingrese las herramientas de análisis estático. Puedes hacer las cosas más difíciles con ellos ...
Y el goto, eso suena como una pesadilla por las mismas razones, pero en cualquier lugar al azar en el código.
En lo que concierne a este programador, Anidado si / no considerado dañino.
Me gusta usar continue al comienzo de los bucles para manejar condiciones simples.
Para mí, hace que el código sea más legible ya que no hay anidación adicional y se puede ver que he tratado explícitamente estos casos.
¿Es esta la misma razón por la que usaría un goto? Quizás. Los uso para facilitar la lectura a veces y para detener el anidamiento del código, pero generalmente los utilizo más para la limpieza / manejo de errores.
No creo que continuar pueda ser tan difícil como ir porque continue nunca mueve la ejecución fuera del bloque de código en el que está.
No hay palabras clave dañinas. Solo hay usos dañinos de ellos.
Goto no es dañino per se, tampoco lo es. Deben usarse con cuidado, eso es todo.
Otros lo insinuaron ... pero el compilador aplica las reglas de continuar y romper y tienen sus propias reglas asociadas. Goto no tiene tales limitaciones, aunque el efecto neto podría ser casi el mismo, en algunas circunstancias.
No considero que continuar o romper sea dañino per se, aunque estoy seguro de que cualquiera de los dos se puede utilizar mal de una manera que haría morder a cualquier programador sensato.
Puede escribir un buen código con o sin continuar y puede escribir un código incorrecto con o sin continuación.
Probablemente haya cierta superposición con los argumentos sobre goto, pero en lo que a mí respecta, el uso de continue es equivalente a usar declaraciones break (en loops) o return statement desde cualquier parte del cuerpo de un método; si se usa correctamente, puede simplificar el código (menos probabilidades de contener errores, más fácil de mantener).
Si continuar está causando un problema con la legibilidad, entonces es probable que tenga otros problemas. Por ejemplo, cantidades masivas de código dentro de un bucle for. Si tiene que escribir bucles for an large, trataré de seguir usando el comando continue cerca de la parte superior del ciclo for. De lo contrario, puede continuar perdiéndose un enterrado profundo en el medio de un bucle for.
Si está iterando a través de cualquier clase de conjunto de resultados, y realizando operaciones en dichos resultados, por ejemplo, dentro de a para cada uno, y si un resultado particular causó un problema, es bastante útil para capturar un error esperado (a través de try-catch), iniciar sesión, y pasar al siguiente resultado a través de continuar. Continuar es especialmente útil, imo, para servicios desatendidos que realizan trabajos a horas inusuales, y una excepción no debe afectar la otra x cantidad de registros.
Yo diría que sí. Para mí, simplemente rompe el ''flujo'' de una pieza de código escrita con fluidez.
Otro argumento podría ser que si se apega a las palabras clave básicas admitidas por la mayoría de los lenguajes modernos, entonces el flujo de su programa (si no la lógica o el código) podría ser portado a cualquier otro idioma. Tener una palabra clave no compatible (es decir, continuar o ir) lo rompería.
En realidad, es más una preferencia personal, pero nunca tuve que usarla y realmente no la considero una opción cuando estoy escribiendo un código nuevo. (Igual que goto)
Yo diría: "depende".
Si tiene un código de bucle razonablemente pequeño (donde puede ver todo el código de bucle sin desplazarse) normalmente está bien utilizar un continuar.
Sin embargo, si el cuerpo de los bucles es grande (por ejemplo, debido a un gran interruptor), y hay algún código de seguimiento (digamos debajo del interruptor), puede introducir fácilmente errores añadiendo un continuar y omitiendo ese código a veces. Me he encontrado con esto en el corazón de un intérprete de códigos de bytes, donde algunas veces el código de instrumentación no se ejecutaba debido a una continuación en algunas ramificaciones de casos.
Este podría ser un caso artificialmente construido, pero generalmente trato de evitar continuar y usar un if (pero no anidando demasiado profundo como en el código de muestra de Rob).
goto puede usarse como una continuación, pero no al revés.
Puedes "ir a goto" a cualquier lugar, así romper el control de flujo arbitrariamente.
Por lo tanto, continuar, no tan dañino.