Regla 0x100Fh: Prohibición de cláusula else redundante tras sentencia de retorno anticipado

0x100Fh: Prohibición de cláusula else redundante tras sentencia de retorno anticipado¶

Enunciado normativo¶

Si la rama de un if concluye incondicionalmente con return, break, continue o exit, NO DEBE escribirse la cláusula else posterior. Las sentencias de la rama alterna DEBEN desanidarse al nivel de la estructura.

¿Por qué existe esta regla?¶

El problema¶

El else posterior a un retorno nunca aporta semántica: si se ejecutó el return, el else no se alcanza; si no se ejecutó, el else se ejecuta porque es lo que sigue. El else solo agrega un nivel de indentación que empuja el camino principal a la derecha.

Desanidar mantiene el “camino feliz” al ras del margen y reduce la profundidad del código. Cada nivel de indentación es una condición que el lector debe recordar; eliminarlo libera memoria de trabajo.

Consecuencias de violarla¶

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

El estándar C no prohíbe el else; la regla es de diseño. La cátedra se apoya en las cláusulas de guarda y los retornos anticipados de 0x2001h: Las funciones deben usar cláusulas de guarda y retornos anticipados para reducir la anidación profunda, y en el antipatrón de bloques else superfluos 0x2013h: Detector de bloques else superfluos tras sentencias terminales. Tensión documentada: 0x200Ch: Cada función debe tener a lo sumo un return pide un único return; cuando rija esa regla, se puede desanidar con una variable de resultado en lugar de retornos múltiples.

Alcance y excepciones¶

• Aplica cuando la rama if termina siempre en una salida incondicional.

• Si el if puede terminar sin salir (por ejemplo, un if interno sin else), el else externo puede ser necesario.

• No aplica a cadenas else if: ahí el else encadena una nueva condición.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — else tras return¶

if (error)
{
    return -1;
}
else
{
    procesar_exito();
    return 0;
}

Por qué falla: el else solo agrega un nivel. El camino exitoso bien podría estar al ras, sin la condición negativa pendiente.

❌ Contraejemplo 2 — else tras continue¶

for (size_t i = 0; i < n; i++)
{
    if (valores[i] < 0)
    {
        continue;
    }
    else
    {
        suma += valores[i];
    }
}

Por qué falla: el else es innecesario porque el continue ya cortó la rama. Además, el continue está prohibido por 0x1002h: Restringí el uso de break y continue; preferí lazos con bandera de control; conviene reescribir la condición.

✅ Ejemplo conforme 1 — flujo desanidado¶

if (error)
{
    return -1;
}

procesar_exito();
return 0;

El camino principal queda al margen y la guarda if (error) se lee como una salida temprana.

✅ Ejemplo conforme 2 — validación con guarda¶

bool procesar(const char *nombre)
{
    if (nombre == NULL)
    {
        return false;
    }

    ejecutar(nombre);
    return true;
}

La condición de error sale temprano y el camino feliz no acumula else ni indentación (ver 0x2001h: Las funciones deben usar cláusulas de guarda y retornos anticipados para reducir la anidación profunda).

⚠️ Casos límite¶

• else if: no es un else redundante; encadena una condición distinta y se conserva.

• Regla de único return: si 0x200Ch: Cada función debe tener a lo sumo un return está activa, reemplazar por una variable resultado y una sola salida.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿La rama if termina siempre con return, break, continue o exit?

• Si es así, ¿eliminé el else y desanidé?

• ¿Distinguí los else if legítimos de los else redundantes?

Reglas relacionadas¶

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

• 0x2013h: Detector de bloques else superfluos tras sentencias terminales — bloques else superfluos tras sentencias terminales.

• 0x200Ch: Cada función debe tener a lo sumo un return — tensión: un único return puede exigir otra estructura.