Regla 0x0202h: No dejes código comentado (dead code) en los archivos fuente

0x0202h: No dejes código comentado (dead code) en los archivos fuente¶

Enunciado normativo¶

NO DEBE dejarse código comentado ni desactivado en los archivos fuente. Toda versión anterior o variante descartada DEBE eliminarse; el historial de cambios pertenece al control de versiones.

Esto incluye comentarios de línea, comentarios de bloque y bloques #if 0.

¿Por qué existe esta regla?¶

El problema¶

El código comentado no muere: queda como una versión paralela que nadie mantiene. Cuando el código activo cambia, el comentado sigue mostrando la lógica vieja y el lector no sabe cuál es la vigente. Además, el compilador no verifica ni el código comentado ni el que está dentro de #if 0, así que puede acumular errores durante años sin que nadie los note.

La herramienta correcta para conservar una versión descartada es el sistema de control de versiones, no el archivo fuente.

Consecuencias de violarla¶

Fundamento en el estándar y en la cátedra¶

El estándar define los comentarios (§6.4.9) como texto descartado por el preprocesador; no dice nada sobre qué conservar. La cátedra adopta el criterio de fuente limpio: el archivo debe contener exactamente el código que se compila, y la historia se consulta en el repositorio.

Alcance y excepciones¶

Aplica a fuentes .c y .h. No debe confundirse con un comentario explicativo (0x0201h: Escribí comentarios que expliquen el ‘porqué’, no el ‘qué’), que sí aporta. El código desactivado temporalmente durante una depuración debe eliminarse antes de la entrega.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Versión anterior comentada¶

// int total = calcular_total_viejo(precio);
int total = calcular_total(precio);

Por qué falla: conserva una función que quizá ya no existe; si alguien descomenta la línea, el compilador falla por símbolo inexistente.

❌ Contraejemplo 2 — Bloque grande con #if 0¶

#if 0
static int procesar_antiguo(int x)
{
    return x * 2;
}
#endif

Por qué falla: el bloque no se compila, no se prueba y no se mantiene, pero ocupa espacio y sugiere que todavía se usa.

✅ Ejemplo conforme 1 — Sin residuos¶

int total = calcular_total(precio);

Justificación: solo queda la versión vigente; la anterior se recupera del historial de Git si hiciera falta.

✅ Ejemplo conforme 2 — Comentario que sí aporta¶

// El redondeo debe ser hacia abajo por la normativa contable.
int total = calcular_total(precio);

Justificación: el comentario explica una decisión de negocio y no contiene código; no hay ambigüedad sobre qué se ejecuta.

⚠️ Casos límite¶

• Depuración activa: mientras se depura, comentar es legítimo; antes de la entrega, se revierte o se elimina.

• Ejemplos en la documentación: un bloque de código dentro de un comentario de cabecera que ilustra el uso de la función puede aceptarse si no parece una versión del código real.

• #if de portabilidad: los bloques condicionales por plataforma sí se compilan en alguna configuración y no cuentan como código muerto.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Eliminé toda línea de código comentada?

• ¿Borré los bloques #if 0?

• ¿El comentario que queda explica y no duplica código?

• ¿Recurrí a Git para conservar versiones anteriores?

Reglas relacionadas¶

• 0x0201h: Escribí comentarios que expliquen el ‘porqué’, no el ‘qué’ — los comentarios explican el porqué, no son código muerto.

• 0x0203h: Prescindí de comentarios obvios, redundantes o vacíos — comentarios vacíos y redundantes van por el mismo camino.

• 0x0001h: La claridad y prolijidad son de máxima importancia — la prolijidad del fuente es el principio rector.

• 0x2003h: Todas las funciones deben incluir documentación completa y estructurada — la documentación estructurada reemplaza a los restos de código.