¿Por qué las declaraciones "if elif else" prácticamente nunca están en formato de tabla?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Dado los ejemplos anteriores, no entiendo por qué prácticamente nunca veo el primer estilo en bases de código. Para mí, usted convierte el código en un formato tabular que muestra claramente lo que desea. La primera columna puede ser virtualmente ignorada. La segunda columna identifica la condición y la tercera columna le proporciona el resultado que desea. Parece, al menos para mí, sencillo y fácil de leer. Sin embargo, siempre veo este tipo simple de situación de caso / cambio en el formato extendido con sangría de pestañas. ¿Porqué es eso? ¿La gente encuentra el segundo formato más legible?

El único caso donde esto podría ser problemático es si el código cambia y se alarga. En ese caso, creo que es perfectamente razonable refactorizar el código en el formato largo con sangría. ¿Todos lo hacen de la segunda manera simplemente porque siempre fue así? Siendo un defensor del diablo, supongo que otra razón podría ser porque las personas encuentran dos formatos diferentes dependiendo de la complejidad de las declaraciones if / else que sean confusas. Cualquier idea sería apreciada.

Una razón puede ser que no estás usando idiomas donde es popular.

Algunos contraejemplos:

Haskell con guardias y con patrones:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang con patrones:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

En general, veo que el formato de tabla es bastante popular entre los lenguajes funcionales (y en los basados ​​en expresiones generales), mientras que romper las líneas es más popular en otros (principalmente basado en declaraciones).

Es más legible. Algunas razones por las cuales:

• Casi todos los idiomas usan esta sintaxis (no todos, la mayoría ; sin embargo, su ejemplo parece ser Python)
• Isanae señaló en un comentario que la mayoría de los depuradores se basan en líneas (no en declaraciones)
• Comienza a verse aún más feo si tienes que poner punto y coma o llaves
• Se lee de arriba a abajo más suavemente
• Parece terriblemente ilegible si tiene algo más que declaraciones triviales de devolución
  • Cualquier sintaxis significativa de sangría se pierde cuando lee el código, ya que el código condicional ya no está visualmente separado (de Dan Neely )
  • Esto será particularmente malo si continúa parcheando / agregando elementos en las declaraciones if de 1 línea
• Solo es legible si todos sus cheques si tienen aproximadamente la misma longitud
• Esto significa que no se puede formatear complicado si negativos en mensajes de varias líneas, que van tienen que ser oneliners
• Es mucho más probable que note errores / flujo lógico cuando leo verticalmente línea por línea, no trato de analizar varias líneas juntas
• Nuestros cerebros leen texto más estrecho y alto MUCHO más rápido que el texto largo y horizontal

En el momento en que intente hacer algo de esto, terminará reescribiéndolo en declaraciones multilínea. ¡Lo que significa que acaba de perder el tiempo!

También la gente inevitablemente agrega algo como:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

No toma mucho tiempo hacer esto antes de decidir que este formato es mucho mejor que su alternativa. ¡Ah, pero podrías incluirlo todo en una sola línea! Enderland muere por dentro .

O esto:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Lo cual es muy, muy molesto. A nadie le gusta formatear cosas como esta.

Y por último, comenzará la guerra santa del problema de "cuántos espacios para pestañas". Lo que se representa perfectamente en su pantalla como un formato de tabla puede no representarse en la mía dependiendo de la configuración.

La legibilidad no debe depender de la configuración IDE de todos modos.

Creo firmemente en que "el código se lee muchas veces, se escribe poco, por lo que la legibilidad es muy importante".

Una cosa clave que me ayuda cuando leo el código de otras personas es que sigue los patrones 'normales' que mis ojos están entrenados para reconocer. Puedo leer la forma sangrada más fácilmente porque la he visto tantas veces que se registra casi automáticamente (con poco esfuerzo cognitivo de mi parte). No es porque sea 'más bonita', es porque sigue las convenciones a las que estoy acostumbrado. Convención late 'mejor' ...

Junto con los otros inconvenientes ya mencionados, el diseño tabular aumenta las probabilidades de conflictos de fusión de control de versión que requieren intervención manual.

Cuando se necesita realinear un bloque de código alineado tabularmente, el sistema de control de versiones tratará cada una de esas líneas como modificadas:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Ahora suponga que, mientras tanto, en otra rama, un programador ha agregado una nueva línea al bloque de código alineado:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

La fusión de esa rama fallará:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Si el código que se modifica no hubiera utilizado la alineación tabular, la fusión habría tenido éxito automáticamente.

(Esta respuesta fue "plagiada" de mi propio artículo desalentando la alineación tabular en el código).

Los formatos tabulares pueden ser muy agradables si las cosas siempre se ajustan al ancho asignado. Sin embargo, si algo excede el ancho asignado, a menudo es necesario tener una parte de la tabla que no esté alineada con el resto o ajustar el diseño de todo lo demás en la tabla para que coincida con el elemento largo .

Si los archivos de origen se editaran utilizando programas diseñados para trabajar con datos de formato tabular y pudieran manejar elementos demasiado largos utilizando un tamaño de fuente más pequeño, dividiéndolos en dos líneas dentro de la misma celda, etc., entonces podría tener sentido usar tabular los formatos son más frecuentes, pero la mayoría de los compiladores quieren archivos fuente que no tengan los tipos de marcas que dichos editores necesitarían almacenar para mantener el formato. El uso de líneas con cantidades variables de sangría pero ningún otro diseño no es tan bueno como el formato tabular en el mejor de los casos, pero no causa tantos problemas en el peor de los casos.

Existe la declaración de "cambio" que proporciona este tipo de cosas para casos especiales, pero supongo que no es eso lo que estás preguntando.

He visto sentencias if en formato de tabla, pero tiene que haber una gran cantidad de condiciones para que valga la pena. 3 si las declaraciones se muestran mejor en el formato tradicional, pero si tenía 20, entonces es mucho más fácil mostrarlas en un bloque grande que esté formateado para hacerlo más claro.

Y ahí está el punto: claridad. Si lo hace más fácil de ver (y su primer ejemplo no es fácil de ver dónde está el delimitador), formateelo para adaptarlo a la situación. De lo contrario, quédese con lo que la gente espera, ya que siempre es más fácil de reconocer.

Si su expresión es realmente tan fácil, la mayoría de los lenguajes de programación ofrecen el operador de ramificación?:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Este es un formato tabular corto y legible. Pero la parte importante es: veo de un vistazo cuál es la acción "principal". Esta es una declaración de devolución! Y el valor se decide por ciertas condiciones.

Si, por otro lado, tiene ramas que ejecutan código diferente, me parece mucho más legible sangrar estos bloques. Porque ahora hay diferentes acciones "principales" dependiendo de la declaración if. En un caso tiramos, en un caso registramos y regresamos o simplemente regresamos. Hay un flujo de programa diferente según la lógica, por lo que los bloques de código encapsulan las diferentes ramas y las hacen más prominentes para el desarrollador (por ejemplo, lectura rápida de una función para captar el flujo del programa)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Como ya dijo Enderland, estás asumiendo que solo tienes un "retorno" como acción, y que puedes etiquetar ese "retorno" al final de la condición. Me gustaría dar algunos detalles adicionales de por qué esto no va a tener éxito.

No sé cuáles son sus idiomas preferidos, pero he estado codificando en C durante mucho tiempo. Hay una serie de estándares de codificación que tienen como objetivo evitar algunos errores de codificación estándar al no permitir construcciones de código que sean propensas a errores, ya sea en la codificación inicial o durante el mantenimiento posterior. Estoy más familiarizado con MISRA-C, pero hay otros, y en general todos tienen reglas similares porque abordan los mismos problemas en el mismo idioma.

Un error popular que los estándares de codificación suelen abordar es este pequeño problema:

if (x == 10)
    do_something();
    do_something_else();

Esto no hace lo que crees que hace. En lo que respecta a C, si x es 10, usted llama do_something(), pero luego do_something_else()se llama independientemente del valor de x . Solo la acción que sigue inmediatamente al enunciado "if" es condicional. Esto puede ser lo que pretendía el codificador, en cuyo caso hay una trampa potencial para los mantenedores; o puede que no sea lo que pretendía el codificador, en cuyo caso hay un error. Es una pregunta de entrevista popular.

La solución en los estándares de codificación es ordenar llaves alrededor de todas las acciones condicionales, incluso si son de una sola línea. Ahora tenemos

if (x == 10)
{
    do_something();
    do_something_else();
}

o

if (x == 10)
{
    do_something();
}
do_something_else();

y ahora funciona correctamente y está claro para los mantenedores.

Notarás que esto es completamente incompatible con tu formato de tabla.

Algunos otros lenguajes (por ejemplo, Python) analizaron este problema y decidieron que, dado que los codificadores usaban espacios en blanco para aclarar el diseño, sería una buena idea usar espacios en blanco en lugar de llaves. Entonces en Python,

if x == 10:
    do_something()
    do_something_else()

hace las llamadas a ambos do_something()y do_something_else()condicional en x == 10, mientras que

if x == 10:
    do_something()
do_something_else()

significa que solo do_something()está condicionado a x, y do_something_else()siempre se llama.

Es un concepto válido, y encontrará que algunos idiomas lo usan. (La vi por primera vez en Occam2, hace mucho tiempo). Sin embargo, una vez más, puede ver fácilmente que su formato de tabla es incompatible con el idioma.

El diseño tabular puede ser útil en algunos casos limitados, pero hay pocas veces que sea útil con if.

En casos simples?: Puede ser una mejor opción. En casos medios, un cambio suele ser mejor (si su idioma tiene uno). En casos complicados, es posible que las tablas de llamadas encajen mejor.

En muchas ocasiones, al refactorizar el código, lo reorganicé para que sea tabular y hacerlo evidente. Es raro que lo deje así, ya que en la mayoría de los casos hay una mejor manera de resolver el problema una vez que lo comprende. Ocasionalmente, una práctica de codificación o estándar de diseño lo prohíbe, en cuyo caso un comentario es útil.

Hubo algunas preguntas sobre ?:. Sí, es el operador ternario (o, como me gusta pensar, el valor si). a primera vista, este ejemplo es un poco complicado para?: (¿y el uso excesivo? solución.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

No veo nada malo con el formato de tabla. Preferencia personal, pero usaría un ternario como este:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

No es necesario repetir returncada vez :)