Alineación vertical: ¿sí o no? [cerrado]

Por ejemplo, alineado no verticalmente:

Name:   Hamt
Version:  0.1.0
Cabal-Version:  >= 1.2
License:  BSD3
Author:  Jason Baker

O alineado verticalmente:

Name:           Hamt
Version:        0.1.0
Cabal-Version:  >= 1.2
License:        BSD3
Author:         Jason Baker

cuál prefieres y por qué?

Personalmente, soy de la opinión de que la segunda versión del código es marginalmente más legible, pero no creo que mantenerlo compense esa legibilidad. Por lo tanto, solo usaría la segunda versión de este ejemplo si estuviera bastante seguro de que el código no cambiaría.

Ahorra tiempo cuando lo haces así:

Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker

No es demasiado difícil de leer tampoco.

Prefiero un híbrido:

Name    : Hamt
Version : 0.1.0
Cabal-Version :  >= 1.2
License : BSD3
Author  : Jason Baker

Que es esencialmente el número 2 con excepciones para líneas ocasionales que son más largas que las líneas circundantes, para evitar que la mayoría de las líneas estén espaciadas.

Aquí hay otra variación para los diseños de listas basados ​​tanto en la experiencia como en la educación de un curso universitario que tomé sobre interacción humano-computadora y varios libros que he leído sobre diseño de interfaz de usuario (G) y diseño gráfico. Lo uso para diálogos, y cuando tengo la energía / tiempo, para CSS (aunque generalmente no para código).

          Name : Hamt
       Version : 0.1.0
 Cabal-Version : >= 1.2
       License : BSD3
        Author : Jason Baker

Como todos los demás, tiene sus pros y sus contras.

Pros:

• Fuerte ruptura visual separa los datos de las etiquetas
• Aspecto de diseño gráfico profesional y estéticamente agradable (especialmente para archivos finalizados y publicados)
• Los datos están más cerca de la etiqueta, lo que facilita la asociación (disminuye las posibilidades de leer a través de una línea los datos incorrectos)
• Ideal para diseños de cuadros de diálogo.

Contras:

• Requiere más tiempo para formatear correctamente
• Requiere realineación cuando se agrega un nuevo elemento más largo
• No tan útil para el código

HTH

Prefiero el primero, pero sin las pestañas (que supongo que son los espacios en blanco); solo un espacio en blanco en su lugar. Para mí, eso es más fácil de leer cuando los datos no son "similares", como en el caso dado. También hace que sea más difícil (mientras edita tales datos) "leer mal una fila", es decir, cuando tiene tres filas con, digamos, números de versión. Y luego, mientras edita uno, edita accidentalmente otro en su lugar.

Sin embargo, cuando los datos son similares, tiene mucho sentido colocarlos en columnas como en su segundo ejemplo (solo que no es similar, pero entiende el punto).

Desafortunadamente, siendo una pregunta de estilo, esto es muy subjetivo y es probable que tenga muchos resultados contradictorios. Además, el estilo a utilizar depende en gran medida del uso de TAB o espacios.


En cuanto a mis dos centavos, prefiero una variación de la segunda versión. Me gusta más esto:

Name            : Hamt
Version         : 0.1.0
Cabal-Version   : >= 1.2
License         : BSD3
Author          : Jason Baker

Es la versión más legible y fácil de usar que he probado. El único inconveniente real es que tengo que descubrir cuál es el campo más amplio y, a veces, terminar expandiéndolos cuando uno es demasiado ancho (esto generalmente solo ocurre con CSS). Sin embargo, hay algunos puntos que deben considerarse.

Primero, generalmente prefiero TAB en lugar de espacios, sin embargo, la configuración real de TAB varía; por ejemplo, estoy acostumbrado a TAB de 4 espacios para código C (++) o HTML y TAB de 2 espacios para código Pascal o Assembler, mientras que para algunas cosas como CSS, no tengo preferencia por el ancho de TAB. Esta variación complica bastante las cosas, pero luego el editor que uso arroja sus propias complicaciones. Algunos editores le permiten establecer configuraciones TAB por idioma, pero otros no (incluso algunos que tienen perfiles diferentes).

Puede evitar esta complicación renunciando a las TAB a favor de los espacios. Dado que el código generalmente está en una fuente de ancho fijo, usar espacios funciona bien, mientras que si está formateando campos en un formulario, currículum u otro texto sin código y está usando una fuente proporcional, necesitará TAB para mantener las cosas alineadas .

Prefiero TAB en general porque incluso con código de ancho fijo, me resulta frustrante tener que pasar por varios espacios para cada TAB. Recuerdo que los viejos IDE de Borland tenían una opción para pasar el cursor a través de TAB (específicamente longitudes de espacio en blanco enteras) como una sola entidad en lugar de como dos, cuatro, etc. espacios. Eso hizo que sea práctico insertar TAB como espacios al tiempo que hace que la navegación del cursor sea fácil y rápida. Lamentablemente, no he visto ningún editor moderno de Windows que pueda hacer eso.

Finalmente, si otros usarán o no su código juega un gran factor en la elección del estilo. Por lo general, soy el único que usa mi código, por lo que puedo formatear todo según mi gusto sin tener en cuenta los editores o la configuración de los demás. Si está trabajando con otros, deberá tenerlos en cuenta, ya que deberán considerarlo.


En resumen, la legibilidad es buena y muy deseable, sin embargo, la configuración y los editores que usted y otras personas que necesitan usar el código serán importantes al tomar la decisión. Si está solo, también puede usar el formato más legible. Es posible que deba acostumbrarse a usarlo, pero es probable que valga la pena a largo plazo, especialmente cuando necesita volver al código que escribió hace un tiempo: la legibilidad es tan importante como los comentarios para comprender lo que hace el código. Si trabaja con otros, entonces querrá trabajar juntos para establecer algún tipo de guía de diseño para uso del equipo.