Aquí hay un ejemplo muy simplificado . Esta no es necesariamente una pregunta específica del idioma, y le pido que ignore las muchas otras formas en que se puede escribir la función y los cambios que se le pueden hacer. . El color es de un tipo único.
string CanLeaveWithoutUmbrella()
{
if(sky.Color.Equals(Color.Blue))
{
return "Yes you can";
}
else
{
return "No you can't";
}
}
Muchas personas que he conocido, ReSharper, y este tipo (cuyo comentario me recordó que he estado buscando preguntar esto por un tiempo) recomendarían refactorizar el código para eliminar el else
bloqueo dejando esto:
(No recuerdo lo que la mayoría ha dicho, de lo contrario no habría preguntado esto)
string CanLeaveWithoutUmbrella()
{
if(sky.Color.Equals(Color.Blue))
{
return "Yes you can";
}
return "No you can't";
}
Pregunta: ¿Hay un aumento en la complejidad introducido al no incluir el else
bloque?
Tengo la impresión de que la else
intención indica más directamente, al afirmar el hecho de que el código en ambos bloques está directamente relacionado.
Además, encuentro que puedo evitar errores sutiles en la lógica, especialmente después de modificaciones en el código en una fecha posterior.
Tome esta variación de mi ejemplo simplificado (ignorando el hecho del or
operador, ya que este es un ejemplo simplificado a propósito):
bool CanLeaveWithoutUmbrella()
{
if(sky.Color != Color.Blue)
{
return false;
}
return true;
}
Alguien ahora puede agregar un nuevo if
bloque basado en una condición después del primer ejemplo sin reconocer inmediatamente de manera correcta que la primera condición impone una restricción a su propia condición.
Si else
hubiera un bloque presente, quien agregara la nueva condición se vería obligado a mover el contenido del else
bloque (y si de alguna manera lo pasan por alto, la heurística mostrará que el código es inalcanzable, lo que no ocurre en el caso de que uno if
limite a otro) .
Por supuesto, hay otras formas en que el ejemplo específico debe definirse de todos modos, todas las cuales evitan esa situación, pero es solo un ejemplo.
La longitud del ejemplo que di puede sesgar el aspecto visual de esto, así que suponga que el espacio ocupado entre paréntesis es relativamente insignificante para el resto del método.
Olvidé mencionar un caso en el que estoy de acuerdo con la omisión de un bloque else, y es cuando uso un if
bloque para aplicar una restricción que debe cumplirse lógicamente para todos los códigos siguientes, como una verificación nula (o cualquier otra protección) .
else
cláusula (a mi gusto, será aún más legible al omitir los corchetes innecesarios. Pero creo que el ejemplo no está bien elegido, porque en el en el caso anterior, escribiría return sky.Color == Color.Blue
(sin if / else). Un ejemplo con un tipo de retorno diferente a bool probablemente aclararía esto.