¿Debería usarse "else" en situaciones donde el flujo de control lo hace redundante?

A veces me encuentro con un código similar al siguiente ejemplo (lo que esta función hace exactamente está fuera del alcance de esta pregunta):

function doSomething(value) {
  if (check1(value)) {
    return -1;
  }
  else if (check2(value)) {
    return value;
  }
  else {
    return false;
  }
}

Como se puede ver, if, else ify elselas declaraciones se utilizan en conjunción con el returncomunicado. Esto parece bastante intuitivo para un observador casual, pero creo que sería más elegante (desde la perspectiva de un desarrollador de software) eliminar los else-s y simplificar el código de esta manera:

function doSomething(value) {
  if (check1(value)) {
    return -1;
  }
  if (check2(value)) {
    return value;
  }
  return false;
}

Esto tiene sentido, ya que todo lo que sigue a una returndeclaración (en el mismo ámbito) nunca se ejecutará, haciendo que el código anterior sea semánticamente igual al primer ejemplo.

¿Cuál de los anteriores se ajusta más a las buenas prácticas de codificación? ¿Hay algún inconveniente en cualquiera de los métodos con respecto a la legibilidad del código?

Editar: se ha hecho una sugerencia duplicada con esta pregunta como referencia. Creo que mi pregunta toca un tema diferente, ya que no estoy preguntando por evitar declaraciones duplicadas como se presenta en la otra pregunta. Ambas preguntas buscan reducir las repeticiones, aunque de maneras ligeramente diferentes.

Me gusta el que no tiene elsey he aquí por qué:

function doSomething(value) {
  //if (check1(value)) {
  //  return -1;
  //}
  if (check2(value)) {
    return value;
  }
  return false;
}

Porque hacer eso no rompió nada de lo que se suponía que no debía hacerlo.

Odio la interdependencia en todas sus formas (incluida la denominación de una función check2()). Aísle todo lo que pueda aislarse. A veces necesitas elsepero no veo eso aquí.

Creo que depende de la semántica del código. Si sus tres casos dependen uno del otro, indíquelo explícitamente. Esto aumenta la legibilidad del código y hace que sea más fácil de entender para cualquier otra persona. Ejemplo:

if (x < 0) {
    return false;
} else if (x > 0) {
    return true;
} else {
    throw new IllegalArgumentException();
}

Aquí depende claramente del valor de xen los tres casos. Si omitiera el último else, esto sería menos claro.

Si sus casos no dependen directamente el uno del otro, omítalo:

if (x < 0) {
    return false;
}
if (y < 0) {
    return true;
}
return false;

Es difícil mostrar esto en un ejemplo simple sin contexto, pero espero que entiendas mi punto.

Yo prefiero la segunda opción (separar ifssin else ify principios return) pero eso es todo el tiempo que los bloques de código son cortos .

Si los bloques de código son largos, es mejor usarlo else if, porque de lo contrario no tendría una comprensión clara de los diversos puntos de salida que tiene el código.

Por ejemplo:

function doSomething(value) {
  if (check1(value)) {
    // ...
    // imagine 200 lines of code
    // ...
    return -1;
  }
  if (check2(value)) {
    // ...
    // imagine 150 lines of code
    // ...
    return value;
  }
  return false;
}

En ese caso, es mejor usarlo else if, almacenar el código de retorno en una variable y tener solo una oración de retorno al final.

function doSomething(value) {
  retVal=0;
  if (check1(value)) {
    // ...
    // imagine 200 lines of code
    // ...
    retVal=-1;
  } else if (check2(value)) {
    // ...
    // imagne 150 lines of code
    retVal=value;
  }
  return retVal;
}

Pero como uno debería esforzarse por que las funciones sean cortas, yo diría que sea breve y salga temprano como en su primer fragmento de código.

Yo uso ambos en diferentes circunstancias. En una verificación de validación, omito lo demás. En un flujo de control, uso lo demás.

bool doWork(string name) {
  if(name.empty()) {
    return false;
  }

  //...do work
  return true;
}

vs

bool doWork(int value) {
  if(value % 2 == 0) {
    doWorkWithEvenNumber(value);
  }
  else {
    doWorkWithOddNumber(value);
  }
}

El primer caso se lee más como si estuviera comprobando todos los requisitos previos primero, quitándolos del camino y luego avanzando al código real que desea ejecutar. Como tal, el código jugoso que realmente desea ejecutar pertenece directamente al alcance de la función; de eso se trata realmente la función.
El segundo caso se lee más como si ambas rutas fueran un código válido para ejecutarse que son tan relevantes para la función como el otro en función de alguna condición. Como tal, pertenecen en niveles de alcance similares entre sí.

La única situación que he visto que realmente importa es un código como este:

List<?> toList() {
    if (left != null && right != null) {
        Arrays.asList(merge(left, right));
    }
    if (left != null) {
        return Arrays.asList(left);
    }
    if (right != null) {
        return Arrays.asList(right);
    }
    return Arrays.asList();
}

Claramente hay algo mal aquí. El problema es que no está claro si returndebe agregarse o Arrays.asListeliminarse. No puede solucionar esto sin una inspección más profunda de los métodos relacionados. Puede evitar esta ambigüedad utilizando siempre bloques if-else completamente exhaustivos. Esta:

List<?> toList() {
    if (left != null && right != null) {
        Arrays.asList(merge(left, right));
    } else if (left != null) {
        return Arrays.asList(left);
    } else if (right != null) {
        return Arrays.asList(right);
    } else {
        return Arrays.asList();
    }
}

no se compilará (en idiomas estáticamente controlados) a menos que agregue un retorno explícito primero if.

Algunos idiomas ni siquiera permiten el primer estilo. Intento usarlo solo en un contexto estrictamente imperativo o para condiciones previas en métodos largos:

List<?> toList() {
    if (left == null || right == null) {
        throw new IllegalStateException()
    }
    // ...
    // long method
    // ...
}

Tener tres salidas de la función como esa es realmente confuso si está tratando de seguir el código y una mala práctica.

Si tiene un único punto de salida para la función, se requieren los otros.

var result;
if(check1(value)
{
    result = -1;
}
else if(check2(value))
{
    result = value;
}
else 
{
    result = 0;
}
return result;

De hecho, vamos aún más lejos.

var result = 0;
var c1 = check1(value);
var c2 = check2(value);

if(c1)
{
    result = -1;
}
else if(c2)
{
    result = value;
}

return result;

Es justo que pueda argumentar por un solo retorno temprano de la validación de entrada. Simplemente evite envolver todo el volumen si su lógica en un if.

Prefiero omitir la declaración redundante else. Cada vez que lo veo (en la revisión de código o refactorización) me pregunto si el autor entendió el flujo de control y que podría haber un error en el código.

Si el autor creía que la declaración else era necesaria y, por lo tanto, no entendía las implicaciones del flujo de control de la declaración return, tal falta de comprensión es una fuente importante de errores, en esta función y en general.