Regla 0x0110h: Los booleanos se nombran con prefijo interrogativo

0x0110h: Los booleanos se nombran con prefijo interrogativo¶

Enunciado normativo¶

Las variables y funciones de tipo bool DEBEN nombrarse de modo que se lean como una pregunta cuya respuesta es sí o no, usando prefijos como es_, esta_, tiene_, puede_, hay_ o debe_.

¿Por qué existe esta regla?¶

El problema¶

Un booleano llamado dato o flag no indica qué afirma sobre el mundo. El lector debe ir a buscarlo en la asignación para saber si dato verdadero significa “hay datos” o “los datos son válidos”. Con un nombre interrogativo, la condición se lee como una frase: if (hay_datos) se entiende sin contexto.

La convención también distingue visualmente los booleanos de los enteros, que en C comparten representación. Un int llamado activo es ambiguo; un bool es_activo no.

Consecuencias de violarla¶

Fundamento en la cátedra¶

Extiende 0x0101h: Los identificadores deben ser descriptivos al caso particular de los booleanos y se articula con 0x1005h: Reemplazá las condiciones ambiguas basadas en la ‘veracidad’ (truthiness) del tipo de dato, que exige comparar los booleanos contra true/false y no contra números, y con 0x301Ah: Validador de uso idiomático de tipos booleanos estándar, que exige usar el bool estándar.

Alcance y excepciones¶

Aplica a variables, parámetros y funciones que devuelven bool. No aplica a campos de bits ni a códigos de estado numéricos, que tienen su propia convención (0x2007h: Los valores de retorno numéricos deben definirse como constantes de preprocesador o enums).

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Nombre sin pregunta¶

bool dato = leer_entrada();

if (dato) {
    procesar();
}

Por qué falla: no se sabe si dato significa “la lectura tuvo éxito”, “hay datos” o “los datos son válidos”. La condición es incomprensible sin mirar la llamada.

❌ Contraejemplo 2 — Polaridad oculta¶

bool error = detectar_fallo();

if (!error) {
    continuar();    /* doble negación: ¿no hay error? */
}

Por qué falla: el nombre afirma “error” y la condición niega; el lector debe hacer el giro mental en cada uso (ver 0x0111h: Nombrá en positivo y evitá las dobles negaciones).

✅ Ejemplo conforme 1 — Prefijo interrogativo¶

bool hay_datos = leer_entrada();

if (hay_datos) {
    procesar();
}

La condición se lee como una pregunta: “¿hay datos?”.

✅ Ejemplo conforme 2 — Función de predicado¶

static bool es_par(int numero)
{
    return numero % 2 == 0;
}

static bool tiene_permiso(const usuario_t *u, permisos_t p)
{
    return (u->permisos & p) != 0;
}

if (es_par(valor) && tiene_permiso(usuario, ESCRITURA)) {
    /* ... */
}

Las llamadas se leen como frases afirmativas; el prefijo es_/tiene_ identifica el rol booleano de inmediato.

⚠️ Casos límite¶

• Booleanos de biblioteca: funciones estándar como feof no siguen la convención, pero su significado ya está fijado por el estándar.

• Nombres de dominio: si el dominio ya tiene una palabra clara (“vigente”, “caducado”), se admite como excepción documentada.

• Negativos: prefiera siempre la forma positiva; es_valido antes que no_es_invalido (0x0111h: Nombrá en positivo y evitá las dobles negaciones).

Cómo detectarla¶

Checklist de autocontrol¶

• ¿El nombre del booleano se lee como una pregunta?

• ¿La polaridad es positiva?

• ¿Distingo el booleano de un entero por el nombre?

• ¿El tipo es bool de <stdbool.h>?

Reglas relacionadas¶

• 0x0101h: Los identificadores deben ser descriptivos — identificadores descriptivos.

• 0x1005h: Reemplazá las condiciones ambiguas basadas en la ‘veracidad’ (truthiness) del tipo de dato — comparación explícita de booleanos.

• 0x301Ah: Validador de uso idiomático de tipos booleanos estándar — tipo bool estándar.

• 0x0111h: Nombrá en positivo y evitá las dobles negaciones — nombrar en positivo.