innecesaria 'otra cosa' declaración

Question

Como saben, en Eclipse puede activar el "innecesaria 'otra cosa' declaración" comprobar que activará el if-then-else con retorno prematuro. Y, desde mi experiencia, hay dos situaciones más posibles cuando el uso de tal declaración:

1) Pre-registro:

if (!validate(arg1)) { 
    return false; 
} 
doLotOfStuff(); 

2) Post-cheque:

doLotOfStuff(); 
if (condition) { 
    return foo; 
} else { 
    return bar; 
} 

En el segundo caso, si el gatillo está encendido, Eclipse le sugerirá que cambie el código para:

doLotOfStuff(); 
if (condition) { 
    return foo; 
} 
return bar; 

Sin embargo, creo que t él return con else declaración es más legible, ya que es como el mapeo directo de la lógica de negocios. Así que soy curioso si esta convención de código "Innecesaria 'else' declaración" es generalizada o si el código es , ¿es más preferible la declaración?

Answer 1

En general, preferiría que la estructura del código siguiera la estructura de la lógica de "negocios" subyacente. En este caso, mi enfoque dependería de lo que represente condition. Si se trata de una comprobación de error, por ejemplo, que normalmente no se ejecutará, pero que puede utilizarse ocasionalmente, la asimetría de la segunda forma coincide con la asimetría de la lógica.

doLotOfStuff(); 
if (condition) { 
    return foo; 
} 
return bar; 

Pero si cualquiera de las posibilidades es razonable y es simplemente una elección entre ellos, que permitiría a la estructura del código para mostrar que la simetría.

doLotOfStuff(); 
if (condition) { 
    return foo; 
} else { 
    return bar; 
} 

El código está allí para que lo lea el programador, no el compilador.

Answer 2

Sé que sin que el IDE compruebe esto por mí, casi siempre uso la declaración else innecesaria. A menudo me parece que se lee mejor inicialmente con él, pero generalmente lo elimino cuando se lo señala, ya que puedo ver el hecho de que es innecesario y luego me molesta ...

Answer 3

Bueno, creo que usar el retorno múltiple es no se puede leer.

prefiero código como:

String result = null; 

doLotOfStuff(); 
if (condition) { 
    result = foo; 
} else { 
    result = bar; 
} 

return result; 

vuelve múltiple es complicado de entender. Pero en su caso voy a preferir el postCheck

doLotOfStuff(); 
if (condition) { 
    return foo; 
} else { 
    return bar; 
} 

Answer 4

Una vez se consideró (y probablemente todavía sea por algunos) que las funciones deben tener un punto de entrada (fácil, pero era relevante si tenemos en cuenta el lenguaje ensamblador) y una salida punto.

Un punto de salida es bueno desde el punto de vista de depuración (como puede poner un reloj/pausa en una línea y saber que lo atravesará) pero puede provocar un anidamiento horrible, por lo que la legibilidad tiende a ganar. ¿Qué produce la menor anidación, las menos líneas de código y el resultado final más legible? En última instancia, eso tiende a ser mucho más importante que cualquier otra cosa.

Por lo que vale la pena el último se puede expresar mejor como:

return condition ? foo : bar; 

asumiendo condition no es terriblemente largo.

No se preocupe demasiado por la supuesta "pureza" del código. Es una distracción irrelevante. Haz que las cosas sean legibles y, en general, sean consistentes.

Answer 5

Algunos de los programadores afirman que return en el medio de la función es una mala práctica. Tal vez para verificar fácilmente en la entrada de la función como en su primer ejemplo, está bien y es aceptable, pero en otros casos prefiero configurar result variable como en la respuesta de Jerome.

Answer 6

me parece esta forma

doLotOfStuff(); 
if (condition) { 
    return foo; 
} 
return bar; 

para ser más legible que la que tiene el otro, es menos código y más intuitivo si se piensa en ello como una declaración de guardia como en Refactoring de Fowler.

Question about multiple return points.

Answer 7

me llama un chico malo, pero por lo general me iría con:

doLotOfStuff(); 
return condition ? foo : bar; 

instrucción de retorno simple, muy fácil de leer.

Answer 8

Si rastreé el siguiente código, notaré que el primer bloque if es un bloque de código excepcional. Sin embargo, si agrego un "else" a eso, puedo tratar que ambos sean bloques de código operativos.

Además, para el bloque operativo principal, puede haber algunos bloques anidados. Prefiero minimizar el nivel anidado.

public String myMethod(input) { 
    if (!validate(input)) { 
     return "invalid input"; 
    } 

    operation1(); 
    if (someCondition) { 
     operation2(); 
    } else { 
     operation3(); 
    } 
    operation4(); 
    operation5(); 
    return operation6(); 
} 

Answer 9

En mi opinión, la comprobación del eclipse no es muy útil. Lo que debe hacer depende del contexto de su programa. Otras cláusulas son para alternativas (ya sea esto o aquello), mientras que pasar a una cláusula de retorno (ninguna) es más apropiado cuando tienes una serie de condiciones que pueden ser ciertas y la caída es más una reacción predeterminada que no lo haces realmente invocar con demasiada frecuencia. Entonces, usa ambos en el código que transmite significado y, como tal, no es útil verificar la presencia o la ausencia.

Answer 10

Bueno, algunos expertos de Java bien conocidos argumentan que siempre se debe luchar para minimizar el alcance de las cosas y esa también es mi opinión.

Mis profesores en la universidad siempre me atormentado que tengo que escribir cosas como esta tal como fue anunciado por alguien antes:

String result = null; 
doLotOfStuff(); 
if (condition) { 
    result = foo; 
} else { 
    result = bar; 
} 
return result; 

El resultado variable tiene ahora un alcance bastante grande. Además, con una gran cantidad de anidamiento esto tiende a ser muy ilegible si haces un poco más aquí, digamos que tienes otro ciclo for-loop.

creo que esto es mucho mejor:

doLotOfStuff(); 
return condition ? foo : bar; 

Esto es directo al grano. Veo de inmediato lo que está pasando, sin revisar las llaves.

creo que es muy bueno para

• Minimizar alcance
• Minimizar sangría (es decir evitar llaves)
• minimizar la longitud método

La advertencia "innecesario else" ayuda con ese.