Regla 0x000Bh: Prohibición de espacios en blanco alrededor de operadores de acceso a miembros (-> y .)

0x000Bh: Prohibición de espacios en blanco alrededor de operadores de acceso a miembros (-> y .)¶

Enunciado normativo¶

NO DEBE dejarse espacio en blanco ni antes ni después de los operadores -> y .. La expresión de acceso DEBE escribirse sin cortes: nodo->sig, punto.x.

El operador une un objeto con el nombre de su miembro.

¿Por qué existe esta regla?¶

El problema¶

-> y . son operadores de acceso a miembros (§6.5.2.3): actúan como un punto que conecta un contenedor con una de sus partes. El espacio alrededor sugiere que son operadores binarios comunes y separa visualmente lo que debe leerse como una única referencia.

nodo -> sig obliga a reconstruir que nodo y sig están unidos; con nodo->sig la cadena de acceso se lee de corrido, igual que una ruta de archivo.

Consecuencias de violarla¶

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

El estándar define -> y . como operadores de sufijo del acceso a miembros (§6.5.2.3) y permite separar sus tokens con espacios (§6.4). La cátedra los escribe adheridos para que la cadena de acceso se lea como una unidad, en coherencia con 0x0005h: El asterisco de los punteros debe declararse junto al identificador y 0x0009h: Espaciado consistente en declaraciones de doble puntero (tipo **var).

Alcance y excepciones¶

Aplica a accesos mediante puntero (->) y mediante valor (.), incluidas las cadenas a->b->c y a.b.c. Los designadores de inicializadores (.campo = valor) también escriben el punto pegado al nombre del campo. No alcanza al punto decimal de un literal (3.14).

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Espacios en ambos operadores¶

nodo -> sig = punto . x;

Por qué falla: dos accesos consecutivos separados por espacios; la línea se lee como cuatro operandos y un supuesto operador binario en el medio.

❌ Contraejemplo 2 — Espacio solo antes o solo después¶

nodo-> sig = punto. x;

Por qué falla: el punto o la flecha fluctúan respecto del nombre; aunque compile, el acceso deja de verse como una ruta continua.

✅ Ejemplo conforme 1 — Acceso continuo¶

nodo->sig = punto.x;

Justificación: cada operador queda pegado a sus dos extremos y la asignación se lee como “el miembro sig de nodo recibe la x de punto”.

✅ Ejemplo conforme 2 — Cadena de accesos y designador¶

struct config_t config = { .puerto = 8080, .host = "localhost" };
int activo = lista->cabeza->dato;

Justificación: en el designador el punto va pegado al campo y en la cadena -> une cada eslabón sin cortes, de modo que la estructura de la lista se sigue de izquierda a derecha.

⚠️ Casos límite¶

• Punto decimal: 3.14 y 0.5 no son accesos a miembros; la regla no se aplica al punto del literal flotante.

• Directivas de preprocesador: #define .campo no es una construcción válida; no hay excepción aplicable.

• -> en macros: una macro que expanda a un acceso debe respetar la misma regla para no ofuscar el código.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Escribí nodo->sig sin espacios?

• ¿Escribí punto.x sin espacios?

• ¿Revisé las cadenas de accesos múltiples?

• ¿Dejé el punto decimal de los flotantes sin tocar?

Reglas relacionadas¶

• 0x0005h: El asterisco de los punteros debe declararse junto al identificador — asterisco de puntero junto al identificador.

• 0x0009h: Espaciado consistente en declaraciones de doble puntero (tipo **var) — espaciado de doble puntero.

• 0x0003h: Un espacio antes y después de cada operador binario — espaciado de operadores binarios (no aplica a ->).

• 0x3004h: Utilizá typedef para definir tipos de estructuras con el sufijo _t — campos de struct accedidos por nombre.

• 0x000Fh: Prohibición de múltiples espacios en blanco consecutivos dentro de una línea de código — prohibición de espacios múltiples.