Regla 0x1007h: No utilizar el operador condicional (ternario) ?:

0x1007h: No utilizar el operador condicional (ternario) ?:¶

Enunciado normativo¶

NO DEBE usarse el operador condicional ?:. Toda selección entre dos valores DEBE expresarse con una estructura if / else explícita.

¿Por qué existe esta regla?¶

El problema¶

El operador ?: comprime una decisión en una expresión. Esa compresión es cómoda para quien escribe y costosa para quien lee: el ojo debe resolver dos ramas mezcladas con la expresión que las contiene. El problema se multiplica cuando el ternario es el argumento de una llamada, cuando anida otro ternario o cuando sus ramas tienen efectos secundarios.

La forma if / else separa la decisión del cómputo. El lector ve explícitamente qué condición se evalúa, qué pasa en cada rama y dónde continúa el flujo.

Consecuencias de violarla¶

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

ISO/IEC 9899:2011 §6.5.15 define el operador condicional y su semántica de cortocircuito. La cátedra lo prohíbe como recurso de estilo porque su valor compresivo es menor que su costo de lectura en el nivel introductorio. El reemplazo es siempre directo con if / else.

Alcance y excepciones¶

• Aplica a cualquier uso de ?:, incluso el más simple.

• No hay excepción por brevedad: dos ramas de asignación se escriben con if / else.

• La regla de espaciado 0x100Ch: Espaciado obligatorio alrededor de operadores ternarios (‘? :’) queda como referencia histórica para código legado; no habilita el uso del operador.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — ternario para elegir un valor¶

int mayor = (a > b) ? a : b;

Por qué falla: obliga a leer la condición y las dos ramas dentro de una única sentencia, y no permite verificar con un punto de corte qué rama se tomó.

❌ Contraejemplo 2 — ternarios anidados¶

const char *estado = (puntaje >= 90) ? "excelente"
                   : (puntaje >= 70) ? "bueno"
                   : (puntaje >= 60) ? "aprobado"
                   : "desaprobado";

Por qué falla: el anidamiento exige reconstruir la asociación de cada :. Un error de umbral es muy difícil de ver; con if / else if la jerarquía es evidente.

✅ Ejemplo conforme 1 — if / else explícito¶

int mayor;
if (a > b)
{
    mayor = a;
}
else
{
    mayor = b;
}

Cada rama es una sentencia separada; la condición y las asignaciones se leen sin mezclarse.

✅ Ejemplo conforme 2 — cadena de if / else if¶

const char *estado;
if (puntaje >= 90)
{
    estado = "excelente";
}
else if (puntaje >= 70)
{
    estado = "bueno";
}
else if (puntaje >= 60)
{
    estado = "aprobado";
}
else
{
    estado = "desaprobado";
}

Los umbrales se leen de mayor a menor y cada caso tiene su bloque, con la estructura de decisión completamente visible.

⚠️ Casos límite¶

• Dos valores simples: aun para a > b se usa if / else; la brevedad no justifica la compresión.

• Inicialización de const: si se necesita const, se puede calcular con una función auxiliar y asignar el resultado una sola vez.

• Código heredado: al migrarlo, reemplazar cada ternario por su if equivalente; no basta con agregar espacios.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Sustituí cada ?: por un if / else?

• ¿Algún ternario quedó anidado y oculto en una expresión mayor?

• ¿Las ramas con efectos secundarios son ahora sentencias separadas?

• ¿Nombré una función auxiliar si necesitaba un valor const?

Reglas relacionadas¶

• 0x100Ch: Espaciado obligatorio alrededor de operadores ternarios (‘? :’) — espaciado del ternario en código legado.

• 0x1004h: Las condiciones complejas deben simplificarse o comentarse — condiciones complejas: extraer y nombrar en lugar de comprimir.

• 0x100Fh: Prohibición de cláusula else redundante tras sentencia de retorno anticipado — desanidar con retornos anticipados en lugar de encadenar.