2012-06-20 19 views
7

pregunta muy simple:Estilo preferido de Python (o cualquier idioma, realmente): ¿Debería usarse de otra forma si se devuelve?

Específicamente en Python (ya que Python tiene en realidad "muy recomendable" guías de estilo especificado en PEP 8, pero en realidad esto se aplica a cualquier idioma), en caso de una función con una cláusula de if que vuelve siempre tienen la alternativa código en una cláusula else o no? En otras palabras, func_style_one() y func_style_two() en el siguiente fragmento de código son (obviamente) exactamente equivalente:

def func_style_one(): 
    if some_conditional_function(): 
     do_something() 
     return something() 
    else: 
     do_something_else() 
     return something_else() 

def func_style_two(): 
    if some_conditional_function(): 
     do_something() 
     return something() 
    do_something_else() 
    return something_else() 

Obviamente, la mejor y más legible estilo depende de la situación, y opiniones variará en gran medida de que es mejor, pero estoy preguntando cuál es específicamente preferido por la comunidad principal de Python. (Por ejemplo, ¿cuál se usa con más frecuencia en la biblioteca estándar, siendo todo lo demás igual?)

+2

Tiendo a elegir el segundo –

+1

Creo que el segundo es más seguro. Menos propenso a cambiar un else a un elif durante un refactor y crear accidentalmente una ruta de código sin valor de retorno. –

+0

Si todo lo que hace el resto es regresar, entonces el primero. Si el otro hace un cálculo adicional, el segundo. –

Respuesta

3

Como regla general, siempre debe evitar agregar complejidad innecesaria a su código, sea cual sea el idioma. También a menudo es una buena idea tratar de dividir su código en subsecciones semánticamente malas.

Dadas estas heurísticas, no hay una respuesta definitiva. Realmente se reduce a lo que estás tratando de lograr.

Lo demostraré con ejemplos.

Si tenemos una función que comprueba si hay varias condiciones de error antes de continuar, podría tener sentido para escribir sin else:

def do_stuff(): 
    if error1(): 
     return cleanup_and_fail() 
    return ok() 

Esto es mejor, ya que a menudo terminan haciendo el registro de varios errores de forma similar en una secuencia:

def do_stuff(): 
    if error1(): 
     return cleanup_and_fail() 
    if error2(): 
     return do_different_cleanup_and_fail() 
    return ok() 

Sin embargo, si su función en lugar de dos ramas ramas iguales, es semánticamente podría tener más sentido que otra cosa:

def do_stuff(): 
    if option1(): 
     return do_option1() 
    else: 
     return do_option2() 

Esto se debe a que a menudo terminan añadiendo varias otras opciones con elif:

def do_stuff(): 
    if option1(): 
     return do_option1() 
    elif: 
     return do_option2() 
    else: 
     return do_option3() 

Para resumir: piensa en la semántica de su código y elige la sintaxis en consecuencia.

+1

Gracias por la respuesta. Esto es típicamente lo que hago, solo me preguntaba si hubo algún consenso, por ej. WWGD (¿Qué haría Guido?). Pero es bueno saber que otros programadores piensan de manera similar. –

+0

Al menos eso creo. También realmente aprecio que estés adoptando PEP 8 - las personas leen guías de estilo muy poco. Sin embargo, las guías de estilo siempre son reglas suaves: si el problema en cuestión requiere que te desvíes de ellas, entonces deberías hacerlo. Por ejemplo, si está extendiendo una aplicación de Python con convenciones de nomenclatura similares a Java, puede ser mejor usar esa convención en lugar de lo que PEP 8 sugiere estrictamente. – jsalonen

+1

Para retornos condicionales triviales como los que da aquí, creo que un mecanismo de mapeo ('options = ['opt1', 'opt'2] return options [opt]') es más claro y más fácil de mantener. Con condicionales más complejos, especialmente con otras condiciones anidadas dentro de las condiciones, puede ser difícil garantizar que cada ruta de código tenga un valor de retorno, por lo que tener la última línea del método es un retorno predeterminado que hace que todo sea más fácil de administrar a largo plazo. correr. Por supuesto, si un valor predeterminado no tiene sentido contextualmente, no debería tener uno, pero luego 'else' tampoco tiene sentido. –

Cuestiones relacionadas