Regla 0x100Bh: No utilices comparaciones en estilo Yoda ('CONST == variable')

0x100Bh: No utilices comparaciones en estilo Yoda (‘CONST == variable’)¶

Enunciado normativo¶

DEBE escribirse la comparación con la variable o expresión a la izquierda y la constante a la derecha: variable == CONSTANTE. NO DEBE invertirse el orden para obtener CONSTANTE == variable.

¿Por qué existe esta regla?¶

El problema¶

El estilo Yoda nació como defensa artesanal: si se escribe 0 == x y el autor teclea = en lugar de ==, el compilador rechaza la asignación a un literal. El truco funcionaba en compiladores antiguos sin advertencias, pero hoy es innecesario y tiene un costo.

Invertir el orden obliga al lector a traducir mentalmente: primero lee el valor y después descubre qué se está comparando. El flujo natural del lenguaje es “sujeto, verbo, objeto”: la variable primero. Además, colocar la constante a la izquierda es un arma de doble filo limitada: solo protege contra el error cuando el lado izquierdo es literal, no contra todos los casos.

Consecuencias de violarla¶

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

ISO/IEC 9899:2011 §6.5.9 define el operador == de forma simétrica; el orden es libre. La cátedra impone el orden natural y se apoya en las advertencias de gcc -Wall -Wparentheses (ver 0x1009h: Prohibición de asignaciones simples dentro de condiciones lógicas) para detectar el = accidental. La protección moderna reemplaza al truco.

Alcance y excepciones¶

• Aplica a comparaciones con literales, NULL, '\0', macros y constantes enum.

• No aplica a comparaciones entre dos variables ni a funciones: no hay constante que poner a la izquierda.

• El autofix de gaff reordena la expresión; revisar que no cambie efectos secundarios en el lado móvil.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — NULL y 0 a la izquierda¶

if (NULL == ptr || 0 == count)
{
    liberar();
}

Por qué falla: exige leer primero los valores neutros y después las variables. El orden natural del razonamiento es preguntar por ptr y por count, no por NULL y 0.

❌ Contraejemplo 2 — literal de carácter a la izquierda¶

if ('\n' == caracter)
{
    continuar();
}

Por qué falla: mezcla dos convenciones si en otros puntos del archivo se compara caracter == '\n'. La inconsistencia obliga a releer cada condición.

✅ Ejemplo conforme 1 — orden natural¶

if (ptr == NULL || count == 0)
{
    liberar();
}

La variable va primero y la constante después; el lector sigue el mismo orden en todo el archivo.

✅ Ejemplo conforme 2 — constante enum y macro¶

if (estado == ESTADO_ACTIVO)
{
    reactivar();
}

if (intentos == MAX_INTENTOS)
{
    bloquear();
}

La comparación se lee de izquierda a derecha sin invertir el sujeto, y el = accidental lo detecta el compilador con -Wparentheses.

⚠️ Casos límite¶

• Ambos lados constantes: MAX == LIMITE no tiene “variable”; elegir el orden según el rol semántico y ser consistente.

• Comparación de cadenas: strcmp no usa ==; va a 0x1005h: Reemplazá las condiciones ambiguas basadas en la ‘veracidad’ (truthiness) del tipo de dato.

• Macros con efectos secundarios: reordenar una comparación no debe cambiar cuántas veces se evalúa cada lado.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Alguna comparación pone la constante a la izquierda?

• ¿El archivo usa un único orden en todas las comparaciones?

• ¿El literal = se detectaría con -Wparentheses?

• ¿El reordenamiento preservó los efectos secundarios?

Reglas relacionadas¶

• 0x1009h: Prohibición de asignaciones simples dentro de condiciones lógicas — el = accidental en condiciones es la raíz del estilo Yoda.

• 0x1005h: Reemplazá las condiciones ambiguas basadas en la ‘veracidad’ (truthiness) del tipo de dato — comparaciones explícitas según el tipo del dato.

• 0x3008h: Los punteros nulos deben ser inicializados y comparados con NULL, no con 0 — punteros contra NULL con coherencia semántica.