19 de diciembre de 2020

Un return vs varios returns

La pregunta sobre si es mejor un sólo return o de dónde viene esta idea es muy habitual en los foros de programación. Hay varios puntos de vista a este respecto como es de suponer y se pueden ver en una de las preguntas con más actividad al respecto.

En la respuesta aceptada habla que en realidad viene de la programación estructurada y cuenta el ejemplo con FORTRAN.

Una razón que considero importante, y es la que más me convence, es uno de los comentarios a esta respuesta:

"This doesn't just apply to assembly. There was also some research done at Microsoft (on C codebases) that found multiple returns contributed to higher bug frequency. See: amazon.com/Writing-Solid-Code-20th-Anniversary/dp/1570740550/…"

Lo cuál ya es un fundamento basado en la experiencia y no sólo en opiniones subjetivas de qué lee mejor cada uno.

Él resultado de ese estudio podría explicarse con que si hace falta varios returns es posible que estés en un God Object y tengas que dividir funcionalidad para seguir SOLID (principio de responsabilidad única). Por eso usando buenas prácticas es raro que encuentres un caso para varios returns o no se solucione simplemente con el operador ternario ?:

Pero hay una excepción que me parece razonable: la cláusula de guarda (Guard Clause), la cual tiene sentido.

Éste sería un ejemplo con tres cláusulas.

double getPayAmount() {
    if (isDead)      return deadAmount();
    if (isSeparated) return separatedAmount();
    if (isRetired)   return retiredAmount();

    return normalPayAmount();
};

Y seguiría la verdadera recomendación que es minimizar los returns.

Por último está la idea extremista de que en efecto sólo haya un return, pero porque en POO sólo deberían utilizarse las palabras reservadas new y return y el resto debe ser todo manejado por objetos:

public int max(int a, int b) {
  return new If(
    new GreaterThan(a, b),
    a, b
  );
}

Conclusión

En mi opinión, parece que una Guard Clause podría tener sentido ya que evita validaciones externas al método y es lo primero que se vería en una revisión, manteniendo un único return más al final. En el resto de casos sería mejor evitar varios returns por los datos del estudio citado justo antes y porque parece que en general es más fácil de mantener (depurar y hacer cambios en el código) a costa de ser menos verbose que parece el principal argumento en contra de un único return.

Como es un tema más bien de debate, te invito a que pongas tu punto de vista en los comentarios.

Compárteme

Entradas populares