Regla 0x6002h: Compilá con frecuencia y resolvé el primer error antes de continuar

0x6002h: Compilá con frecuencia y resolvé el primer error antes de continuar¶

Enunciado normativo¶

DEBE compilarse el programa cada vez que se completa una unidad de trabajo pequeña. Ante varios errores, DEBE corregirse primero el primer error reportado y volver a compilar; NO DEBE intentarse corregir todos los errores a la vez leyendo sólo el listado.

¿Por qué existe esta regla?¶

El problema¶

El compilador emite diagnósticos en cascada: un solo error sintáctico puede generar decenas de errores “falsos” que desaparecen al corregir el primero. Si el estudiante intenta arreglarlos todos, edita código que no estaba roto y convierte un error en varios.

Además, cuanto más código se escribe sin compilar, más grande es el intervalo en el que se introdujo un error y más difícil resulta atribuirlo a una decisión concreta. Compilar seguido convierte la depuración en una búsqueda sobre el último cambio, no sobre toda la sesión.

Consecuencias de violarla¶

Fundamento en la cátedra¶

Es el complemento operativo de 0x5002h: Desarrollá y compilá siempre con todas las advertencias del compilador activadas: no alcanza con activar las advertencias, hay que usarlas en cada paso. La compilación frecuente es también la forma más barata de encontrar errores de tipos, firmas y #include antes de llegar al depurador.

Alcance y excepciones¶

Aplica a todo desarrollo, aunque el programa no esté terminado. Compilar un esqueleto incompleto es correcto y esperable. La excepción es el código generado por herramientas, que no se edita a mano.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Escribir doscientas líneas y recién ahí compilar¶

int main(void)
{
    /* ... 180 líneas escritas de una sentada ... */
    return 0;
}

main.c:12: error: expected ';' before '}' token
main.c:34: error: 'n' undeclared (first use in this function)
main.c:35: error: (Each undeclared identifier is reported only once)
... 47 errores más ...

Por qué falla: casi todos los 47 errores derivan de un ; faltante en la línea 12. Corregirlo suele dejar el programa con uno o dos errores reales.

❌ Contraejemplo 2 — Corregir el último error del listado¶

El estudiante lee de abajo hacia arriba y arregla main.c:99. Vuelve a compilar y aparece un error idéntico en main.c:12. Perdió el tiempo en un síntoma.

✅ Ejemplo conforme 1 — Ciclo corto de compilación¶

gcc -Wall -Wextra -Werror -std=c11 -pedantic -c main.c -o main.o

Se compila después de cada función o bloque lógico. El primer error apunta al último fragmento escrito, que es el sospechoso natural.

✅ Ejemplo conforme 2 — Leer el primer diagnóstico completo¶

main.c:12:5: error: expected ';' before '}' token
   11 |     suma += valores[i]
      |                       ^
      |                       ;

Se lee la línea exacta, se interpreta el mensaje y se aplica la corrección sugerida (;), y recién entonces se vuelve a compilar.

⚠️ Casos límite¶

• Muchos errores legítimos: si el primer error es de un #include faltante, corregirlo puede revelar tipos nuevos; es normal, se itera.

• Compilar un archivo suelto: -c permite verificar sintaxis sin enlazar, útil cuando el resto del proyecto aún no compila.

• -Werror: convierte advertencias en errores; si impide avanzar, es preferible entender la advertencia que desactivar la bandera.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Compilé después del último bloque lógico que escribí?

• ¿Corregí el primer error antes de mirar los demás?

• ¿Volví a compilar tras cada corrección?

• ¿El listado final quedó sin errores ni advertencias?

Reglas relacionadas¶

• 0x5002h: Desarrollá y compilá siempre con todas las advertencias del compilador activadas — banderas de advertencia obligatorias.

• 0x6001h: Diseñá el algoritmo antes de escribir código en C — diseñar antes reduce la tasa de errores por intento.

• 0x8003h: Verificá con gcc, gdb y valgrind antes de entregar — verificación con herramientas más allá del compilador.