Regla 0x200Fh: Prohibición de paréntesis superfluos en sentencia return

0x200Fh: Prohibición de paréntesis superfluos en sentencia return¶

Enunciado normativo¶

NO DEBEN envolverse en paréntesis la expresión de una sentencia return. DEBE escribirse return expresion; y usar paréntesis solo cuando la propia expresión los necesite por precedencia.

¿Por qué existe esta regla?¶

El problema¶

return es una palabra clave de control de flujo, no una llamada a función. Por eso return (x); no invoca nada: los paréntesis son ruido sintáctico. Ese ruido tiene dos costos. Primero, sugiere que return es una función, una confusión conceptual que reaparece cuando el estudiante escribe exit (0) o sizeof (int) con el mismo estilo. Segundo, un par de paréntesis de más esconde la expresión real: cuanto más envuelto está el cálculo, más difícil es leer la precedencia.

Consecuencias de violarla¶

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

La gramática de C11 define return con una expresión opcional que ya admite paréntesis como parte de la propia expresión (§6.8.6.4). La norma no prohíbe return (x);: es perfectamente válido. La cátedra lo marca por estilo, en línea con 0x301Bh: Prohibición de casts de tipo innecesarios o redundantes (casts innecesarios) y con la idea de que la forma sintáctica debe reflejar la semántica. Tiene corrección automática porque la transformación no cambia el significado.

Alcance y excepciones¶

Aplica a la expresión completa. No se eliminan los paréntesis internos que la expresión necesita:

• return (a + b) * c; → los paréntesis son de la multiplicación.

• return condicion ? a : b; → sin paréntesis extra.

• return (struct punto_t){x, y}; → los paréntesis son parte del compuesto literal, no del return.

La regla solo quita el par que envuelve toda la expresión.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Paréntesis envolvente simple¶

int suma(int a, int b)
{
    return (a + b);
}

Por qué falla: el paréntesis exterior no cumple ninguna función. La expresión a + b es la misma con o sin él, y sugiere erróneamente que return es una llamada.

❌ Contraejemplo 2 — Paréntesis en cada rama¶

int maximo(int a, int b)
{
    if (a > b) {
        return (a);
    }
    return (b);
}

Por qué falla: además de los paréntesis superfluos, hay dos puntos de salida (0x200Ch: Cada función debe tener a lo sumo un return). El estilo de return (variable); es puro ruido y no aporta claridad sobre cuál es el mayor.

✅ Ejemplo conforme 1 — Retorno directo¶

int suma(int a, int b)
{
    return a + b;
}

La expresión se lee tal cual es. El estilo coincide con el de las funciones de la biblioteca estándar.

✅ Ejemplo conforme 2 — Paréntesis solo donde la precedencia lo exige¶

int escala(int a, int b, int c)
{
    return (a + b) * c;
}

double mitad(int x)
{
    return (double)x / 2.0;
}

En el primer caso el paréntesis define la precedencia de la suma; en el segundo, el cast (double) es necesario. Ninguno es el par envolvente que la regla prohíbe.

⚠️ Casos límite¶

• Literal compuesto: return (struct punto_t){1, 2}; conserva los paréntesis porque pertenecen al compuesto literal.

• Macros: return CUADRADO(x); no lleva paréntesis extra; la macro debe proteger sus parámetros (0x500Ah: Protección obligatoria de parámetros en macros funcionales mediante paréntesis).

• Operador coma: return (a, b); sí necesita el par para no cambiar la gramática; es una excepción legítima, aunque el operador coma en return es un olor y conviene evitarlo.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Mis return escriben la expresión directamente?

• ¿Los paréntesis que quedan son necesarios por precedencia?

• ¿Evité tratar return, exit o sizeof como funciones?

• ¿El estilo es uniforme en todo el archivo?

Reglas relacionadas¶

• 0x301Bh: Prohibición de casts de tipo innecesarios o redundantes — el mismo criterio aplica a los casts innecesarios.

• 0x200Ch: Cada función debe tener a lo sumo un return — el retorno se concentra; esta regla limpia su forma.

• 0x0003h: Un espacio antes y después de cada operador binario — el espaciado alrededor de operadores también cuida la forma.

• 0x2003h: Todas las funciones deben incluir documentación completa y estructurada — el valor documentado debe coincidir con la expresión devuelta.