Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Regla 0x0004h: Cada bloque debe tener una indentación de cuatro espacios respecto a su contenedor y llaves

Sintaxis y formato visual (0x00XX)

Universidad Nacional de Río Negro

0x0004h: Cada bloque debe tener una indentación de cuatro espacios respecto a su contenedor y llaves

Enunciado normativo

DEBE indentarse cada bloque con exactamente cuatro espacios por nivel de anidación respecto de su contenedor. NO DEBE mezclarse tabulaciones con espacios ni usarse anchos distintos dentro del mismo archivo.

La indentación refleja la jerarquía sintáctica del programa.

¿Por qué existe esta regla?

El problema

La indentación es la única señal visual que revela a qué bloque pertenece cada sentencia. Sin ella, un if anidado y su else parecen hermanos, y el intérprete humano del código reconstruye mal el flujo. Cuatro espacios son suficientes para distinguir niveles sin empujar el código fuera de la pantalla cuando hay anidación moderada.

Mezclar tabulaciones y espacios es aún más grave: el mismo archivo se ve distinto en cada editor, y una llave puede aparecer alineada para un lector y desalineada para otro. Lo que el compilador ignora, el revisador lo sufre.

Consecuencias de violarla

Tipo de consecuenciaEfecto concreto
CompilaciónNinguna: el preprocesador descarta el espaciado.
Bug silenciosoAnidación mal percibida produce errores de alcance y de else colgante.
MantenibilidadMover un bloque obliga a reindentar manualmente todo su interior.
Portabilidad visualTabs y espacios se expanden distinto según la configuración del editor.
RevisiónEl diff muestra ruido cuando un editor reindenta con otro criterio.

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

El estándar clasifica los espacios como white-space sin significado (§6.4). La cátedra fija cuatro espacios, en consonancia con el estilo Allman de 0x0007h: Las llaves deben ubicarse en líneas independientes según el estilo Allman, para que llaves y sentencias formen columnas predecibles.

Alcance y excepciones

Aplica a cuerpos de función, estructuras de control, struct, enum y union. Las líneas de continuación de expresiones largas se indentan ocho espacios (dos niveles) o se alinean tras el paréntesis; el case dentro de un switch se indenta un nivel respecto del switch.

Ejemplos exhaustivos

❌ Contraejemplo 1 — Cuerpo sin bloque ni sangría

if (condicion)
accion();

Por qué falla: sin llaves ni indentación no hay pista visual de que accion() depende del if; un cambio futuro agrega otra sentencia y solo la primera queda condicionada.

❌ Contraejemplo 2 — Niveles dispares y tabs mezclados

if (a > b)
{
  if (b > c)
	{
        printf("mayor\n");
    }
}

Por qué falla: el segundo nivel usa dos espacios y el tercero una tabulación; en otro editor la estructura se ve rota.

✅ Ejemplo conforme 1 — Un nivel, cuatro espacios

if (a > b)
{
    if (b > c)
    {
        printf("a es el mayor\n");
    }
}

Justificación: cada nivel agrega exactamente cuatro espacios y las llaves alineadas permiten barrer la jerarquía con la vista.

✅ Ejemplo conforme 2 — switch y continuación

switch (estado)
{
    case ACTIVO:
        procesar();
        break;

    default:
        break;
}

Justificación: el switch no indenta sus llaves y cada case agrega un nivel; la separación con líneas en blanco agrupa visualmente cada rama.

⚠️ Casos límite

Cómo detectarla

HerramientaComandoSeñal
gaffgaff check archivo.c / gaff fix archivo.cIndentación que no es múltiplo de cuatro o mezcla de tabs.
grepgrep -nP '^\t' archivo.cTabulaciones al inicio de línea.
EditorMostrar espacios/tabsColumnas fuera de la rejilla de cuatro.

Checklist de autocontrol

Reglas relacionadas