Regla 0x0104h: Los nombres de los archivos deben usar snake_case en minúsculas (sin espacios)

0x0104h: Los nombres de los archivos deben usar snake_case en minúsculas (sin espacios)¶

Enunciado normativo¶

DEBE nombrarse los archivos fuente y de cabecera en snake_case con minúsculas, sin espacios ni caracteres especiales (lista_enlazada.c, arbol_binario.h). NO DEBE usarse mayúsculas, espacios ni guiones.

Esta regla alcanza también a los nombres citados en los #include.

¿Por qué existe esta regla?¶

El problema¶

En Linux el sistema de archivos distingue mayúsculas de minúsculas. Un archivo Lista.h no es el mismo que lista.h, de modo que un #include "Lista.h" puede fallar en una máquina y funcionar en otra según cómo se haya creado el archivo. Los espacios en los nombres obligan a escapar rutas en la terminal, en los Makefile y en los scripts de corrección.

El nombre del archivo también es un contrato: si modulo.h y modulo.c siguen el mismo patrón, el módulo se reconoce a simple vista.

Consecuencias de violarla¶

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

El estándar no nombra archivos salvo por la forma del #include (§6.10.2), que queda a cargo de la implementación. La cátedra fija snake_case minúsculas para que los #include, los Makefile y los scripts de corrección coincidan sin ambigüedad.

Alcance y excepciones¶

Aplica a archivos .c, .h y a cualquier otro fuente del proyecto (Makefile es el nombre canónico aceptado). Las extensiones van en minúsculas: .c y .h, no .C ni .H. Las herramientas de terceros conservan sus nombres originales.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Mayúsculas y espacios¶

Lista Enlazada.c
ArbolBinario.H

Por qué falla: el espacio obliga a citar la ruta en la terminal y las mayúsculas impiden que #include "lista_enlazada.h" lo encuentre.

❌ Contraejemplo 2 — Guiones en lugar de guiones bajos¶

mi-archivo.c
pila-dinamica.h

Por qué falla: el guion es válido para el sistema de archivos pero rompe la convención snake_case y además se confunde con el operador - al referirse al nombre desde una macro.

✅ Ejemplo conforme 1 — Nombres canónicos¶

lista_enlazada.c
arbol_binario.h

Justificación: todos los caracteres son minúsculas o guiones bajos y cada palabra queda separada de forma uniforme.

✅ Ejemplo conforme 2 — Coincidencia con el #include¶

#include "pila_dinamica.h"
#include "pila_dinamica.h"

Justificación: el nombre del archivo coincide exactamente con el del #include, sin depender de mayúsculas ni de la resolución laxa de un sistema de archivos.

⚠️ Casos límite¶

• Caracteres no ASCII en el nombre: un archivo año.c viola además 0x0108h: Prohibición de identificadores con caracteres no ASCII (acentos, ñ); usá anio.c.

• Directorios: la misma convención se aplica a las carpetas del proyecto.

• Archivos generados: conservan el nombre que les asigna la herramienta, pero conviene aislarlos en su propio directorio.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿El nombre usa solo minúsculas, dígitos y guiones bajos?

• ¿La extensión es .c o .h en minúsculas?

• ¿Cada #include coincide exactamente con el nombre real?

• ¿Evité espacios, guiones y tildes?

Reglas relacionadas¶

• 0x0205h: En archivos .c la inclusión de la cabecera propia debe figurar en primer lugar — la cabecera propia se incluye primero en el .c.

• 0x0108h: Prohibición de identificadores con caracteres no ASCII (acentos, ñ) — identificadores restringidos a ASCII.

• 0x5007h: Inclusiones redundantes o duplicadas de la misma cabecera #include — evitar inclusiones duplicadas de la misma cabecera.

• 0x500Fh: Colisión de nombres de macroguardas entre archivos de cabecera distintos — evitar colisiones de macroguardas entre cabeceras.

• 0x5005h: Organizá la estructura de tus archivos .c de forma estándar — estructura estándar de los archivos .c.