2012-01-18 14 views
23

tengo este método (código modificado):¿Salir de un método vacío?

public static void PublishXmlForCustomTypes(MyOwnClass DefaultOutputInformation) 
{ 
    if (DefaultOutputInformation != null) 
    { 
     ///lot of code 
    } 
} 

y todo mi código estaba dentro de la sentencia if y después de pensarlo, he cambiado a esto:

public static void PublishXmlForCustomTypes(MyOwnClass DefaultOutputInformation) 
{ 
    if (DefaultOutputInformation == null) 
    { 
     return; 
    } 
    ///lot of code 
} 

Por lo que he probado parece ser estrictamente equivalente, pero ¿realmente es así? Quiero decir, la declaración de "devolución" nos saca del método ¿verdad?

Respuesta

36

Esto es estrictamente equivalente y la segunda versión es el camino a seguir :)

+0

¿No hay un caso oculto en el que esto no sea equivalente? –

+0

de acuerdo y votando. Es más fácil para usted y para otros que lo mantendrán más adelante, si el alcance de su bloque IF es lo más pequeño posible, aunque funcionalmente no hace la diferencia. –

+0

@ Jérémy Talio: No, no hay. – BoltClock

1

Sí, su hipótesis es correcta.

Para obtener más información, obtenga más información acerca de duality.

+0

De todos los sitios que eliges Wikipedia. –

+0

@AshBurlaczenko: Mañana esta respuesta será útil :) – leppie

1

Sí, es exactamente la misma, se puede leer la documentación de MSDN sobre el regreso de palabras clave para entender completamente cómo funciona: http://msdn.microsoft.com/en-us/library/1h3swy84.aspx

En cuanto a decidir qué camino es mejor: ambos son buenos, pero la segunda versión lo hace más legible porque entonces todo su código no está dentro de un bloque if. De esta manera, puede ver lo que hace la condición realmente fácil en lugar de leer todo el código del método.

4

return le saca del método; si tiene un bloque finally y llama a return desde el bloque try, el bloque finally se ejecuta de todos modos.

7

Sí, eso está absolutamente bien.

Algunas personas se adhieren dogmáticamente a "un punto de salida por método", que era apropiado cuando era relativamente complicado asegurarse de que siempre realizara la cantidad correcta de limpieza al final de una función en C, por ejemplo. .. pero no es realmente necesario en C#.

Personalmente, creo que es apropiado regresar tan pronto como sepa que ya ha realizado todo el trabajo que realmente desea en un método. Use las declaraciones try/finally o using para realizar cualquier trabajo extra de "limpiar, pero salgo".

+0

Me he encontrado con defensores de una salida punto por método. Entiendo su motivo, pero puede dar como resultado un código bastante desagradable. – ColinE

+0

Yo era una de las personas dogmáticas hasta ahora, era una cuestión de hábito, supongo. – ThePower

+0

@El hábito de ThePower es algo que nos viene naturalmente a todos. Felicitaciones por romperlo ;-) – ColinE

1

De hecho, el return le saca del método, por lo que es equivalente a la primera forma que utilizó. Qué camino es mejor depende de tu código, aunque en general preferiría la segunda versión.

2

Sí, la declaración de return finaliza el método.

2

Sí, la devolución saldrá del código. En general, es una buena práctica como el primer paso de una función verificar que los parámetros pasados ​​son los que usted cree que son y salir (mediante el retorno o lanzar una excepción) para que no haga ningún procesamiento innecesario solo para tiene que abortar más tarde en la función.

1

Al mirar el código revisado, el segundo es el camino a seguir. Si bien es funcionalmente equivalente, piense en el caso en que transfirió 4 variables diferentes a una función que desea verificar. En lugar de hacer una mala declaración de 4 niveles si con {en todas partes, el segundo método le permite limpiar la apariencia del código y no agregar niveles innecesarios de corchetes. Si está escribiendo en C/C++, incluso puede hacer que esta sea una macro como VERYIFY_NOT_NULL (x) y hacer que el código sea agradable y ordenado.

El código legible/mantenible supera los nano segundos de rendimiento el 99% del tiempo.

Cuestiones relacionadas