Regla 0x0111h: Nombrá en positivo y evitá las dobles negaciones

0x0111h: Nombrá en positivo y evitá las dobles negaciones¶

Enunciado normativo¶

Los identificadores DEBEN formularse en positivo. NO DEBE usarse una negación en el nombre seguida de una negación en la condición (if (!no_hay_error)). Cuando exista una forma positiva natural, DEBE preferirse.

¿Por qué existe esta regla?¶

El problema¶

Cada negación en un nombre obliga a invertir mentalmente su significado en cada lectura. Dos negaciones —una en el nombre y otra en el operador— exigen dos inversiones, y el error de una de ellas produce justamente la condición contraria con el mismo aspecto visual.

Un nombre positivo describe un estado afirmativo del mundo; un nombre negativo describe la ausencia de un estado y arrastra la carga de la excepción.

Consecuencias de violarla¶

Fundamento en la cátedra¶

Es una aplicación de 0x0101h: Los identificadores deben ser descriptivos al problema específico de la polaridad. Se combina con 0x0110h: Los booleanos se nombran con prefijo interrogativo, que ya pide nombres afirmativos para los booleanos.

Alcance y excepciones¶

Aplica a variables, funciones y campos. Se conservan las construcciones idiomáticas del lenguaje (NULL, EOF, false) y las constantes de error negativas, que no son nombres de estado. Cuando la negación es inevitable, se prefiere una palabra positiva (sin_datos antes que no_hay_datos).

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Doble negación en la condición¶

bool no_hay_error = verificar();

if (!no_hay_error) {
    reportar_fallo();
}

Por qué falla: la condición se lee “si no (no hay error)” = “si hay error”, pero el lector tarda y puede equivocarse. La variable y la condición niegan dos veces lo mismo.

❌ Contraejemplo 2 — Nombre negativo con lógica positiva¶

bool invalido = validar(entrada);

if (invalido) {
    usar(entrada);      /* parece un error, pero es el camino feliz */
}

Por qué falla: el nombre sugiere que el bloque maneja el error, pero en realidad se ejecuta cuando la entrada es válida. Un revisor cansado leerá lo contrario.

✅ Ejemplo conforme 1 — Positivo directo¶

bool es_valido = validar(entrada);

if (es_valido) {
    usar(entrada);
}

La condición coincide con el nombre; no hay inversión que recordar.

✅ Ejemplo conforme 2 — Guarda con negación legible¶

bool es_valido = validar(entrada);

if (!es_valido) {
    reportar_error();
    return;
}

usar(entrada);

La única negación es la de la guarda, sobre un nombre positivo; es la forma aceptada de expresar el caso de error (0x2001h: Las funciones deben usar cláusulas de guarda y retornos anticipados para reducir la anidación profunda).

⚠️ Casos límite¶

• Predicados estándar: feof, ferror son nombres afirmativos de un estado (fin de archivo, error) y su negación es legible.

• Palabras compuestas: sin_espacio es positivo en la práctica aunque contenga “sin”; es preferible a no_hay_espacio_libre.

• Simetría de pares: al definir un par, ambos deben ser positivos (activo/inactivo), no uno positivo y otro negado.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Puedo reformular el nombre sin partículas negativas?

• ¿La condición usa la misma polaridad que el nombre?

• ¿Cada negación del código es legible de un vistazo?

• ¿El par de estados usa nombres simétricos positivos?

Reglas relacionadas¶

• 0x0110h: Los booleanos se nombran con prefijo interrogativo — booleanos con prefijo interrogativo.

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

• 0x2001h: Las funciones deben usar cláusulas de guarda y retornos anticipados para reducir la anidación profunda — guardas con retorno anticipado.

• 0x1017h: Escribí condiciones afirmativas y directas — condiciones afirmativas y directas.