Uso del espacio en blanco vertical

Question

Mi intención en esta pregunta no es ser pedante, sino más bien explorar un eje pasado por alto de un tema importante (the use of whitespace). Mucho debate y cuidado se ha puesto en el uso del espacio en blanco horizontal, sangría después de un condicional, un espacio entre un si y paréntesis, etc. De hecho, el problema se considera tan importante y polémico que, no solo algunas empresas tiene reglas y estándares para ello, pero algunas compañías incluso tienen reglas que prohíben su discusión.

¿Por qué, teniendo en cuenta el estado del espacio en blanco horizontal, que la discusión del espacio en blanco vertical es un tema tan muerto? ¿Por qué es el x más importante que el y? Hace unos días noté que cuando leo el código, sin pensar, a menudo ajusto las agrupaciones verticales de las declaraciones. Tener código de otros pueblos leer ahora, con la vista puesta en el espacio en blanco vertical, me di cuenta de varios patrones, por lo que pido stackoverflow:

• ¿Qué reglas duras y blandas Cómo se aplica a los espacios en blanco vertical?
• ¿Hay usos verticales en espacios en blanco que generalmente se consideran muy malos o muy buenas prácticas?
• ¿Ha encontrado que leer código con espacios en blanco verticales "correctos" ayudó a entenderlo?
• ¿Alguien más que typographers y nosotros nos preocupamos?

Answer 1

Miro el espacio vertical en el código de la forma en que veo los párrafos en la prosa escrita.Así como un párrafo está destinado a agrupar oraciones que tienen un punto o idea común, las líneas que están relacionadas deben agruparse juntas.

El objetivo general es mejorar la legibilidad del código. Del mismo modo que un artículo sin párrafos sería difícil de leer, también lo es el código sin ningún espacio vertical. Y al igual que con la prosa, existe un equilibrio entre redactar párrafos que son demasiado cortos o demasiado largos. Pero al final, todo se reduce al estilo personal y preferencia.

Answer 2

Ciertamente me importa y tienden a agrupar el código correctamente (al menos para mis ojos) con líneas en blanco cuando corresponda. A veces esto significa muchas líneas en blanco, pero en general considero que el código es más legible que con todo lo demás. Al igual que los espacios alrededor de los operadores son algo muy agradable, por lo que las líneas en blanco se encuentran alrededor de las declaraciones agrupadas lógicamente.

Sin embargo, más de una línea en blanco a la vez parece un poco fuera de lugar.

Answer 3

Me resulta difícil de leer si el código está espaciado de forma vertical irregular. Incluso llevo hasta el punto de quitar llaves que no son necesarias, o si se trata de bloques cortos, como ifs o fors, colóquelos en la misma línea.

Answer 4

Creo que una de las cosas más importantes es agrupar un paso lógico en conjunto, tales como:

foo.setBar(1); 
foo.setBar2(2); 
foo.writeToDatabase(); 

bar.setBar(1) 
bar.setBaz(2); 
bar.writeToDatabase(); 

De esta manera, el código es más fácil de leer, y es más descriptivo, al menos para mí.

Answer 5

Si un grupo de declaraciones está lógicamente relacionado, le doy una línea en blanco antes y después. Esta separación ayuda si necesito refactorizarla en una función más adelante.

En cuanto a las líneas dobles en blanco: si algo es distinto, realmente deberías considerar hacer una función.

Answer 6

Se sabe desde hace décadas que la capacidad de un programador para comprender el código generalmente está limitada por la cantidad de tiempo que puede ver al mismo tiempo. (Véase, por ejemplo, Weinberg, "Psicología de la Programación de Computadoras", un viejo pero bueno). En los viejos tiempos de las listas en papel, los programadores tomaban grandes mesas y diseminaban varias páginas de la lista. Hoy en día, la pantalla de bienes inmuebles es algo mejor que los días de 24x80, pero todavía tiendo a minimizar el uso del espacio en blanco vertical, ya que muchas líneas en blanco ocupan espacio en la pantalla que podría mostrarme el código real.

Answer 7

Si un comentario se aplica a varias líneas de código, pongo espacios en blanco después de la última de esas líneas, a menos que haya otra sintaxis para descomponer las cosas (como el final de un bloque).

Donde sea que esté haciendo "algo" que toma varias líneas de código, inmediatamente seguido de "algo más", entonces abstraeré en funciones separadas o bien colocaré comentarios [*]. Así que las líneas de código generalmente terminan agrupadas en bloques cortos, excepto cuando el control de flujo lo hace (en mi opinión) autoexplicativo.

Me importa un poco el espacio en blanco, pero en realidad son los comentarios que me interesan más. Si unas pocas líneas de código juntas hacen algo específico, y no se ha tomado como una función, entonces me gustaría ver una descripción en inglés de lo que es esa cosa. De esa manera puedo ver que los "pasos" de la función realmente se suman al resultado correcto, luego miro para ver que cada paso hace lo que dice hacer.

En las clases, a veces pongo espacios en blanco entre métodos/funciones de miembros, y otras veces no. En C++ pongo espacios en blanco antes de los especificadores de acceso.

Pongo espacios en blanco entre las clases, (a veces no para las clases internas anónimas en Java) y entre las funciones fuera de las clases.

Aparte de eso, mi código es bastante verticalmente denso. Casi nunca uso múltiples líneas en blanco, incluso al separar secciones de un archivo de cabecera y similares. Prefiero línea en blanco-línea de comentario-línea en blanco en lugar de línea en blanco-línea en blanco, incluso si la línea de comentario termina siendo algo completamente banal como "funciones de ayuda". No me gustan los estilos que tienen espacios en blanco verticales enormes entre las funciones. Si están tan separados que no quieres verlos a los dos en la pantalla al mismo tiempo, diría que los colocas en diferentes archivos o llenas el espacio con Doxygen./Comentarios de Javadoc.

[*] En la versión que ingreso. Generalmente escribo el código más o menos sin comentarios, luego lo compilo, hago pruebas rápidas, lo comento, hago las pruebas adecuadas, lo comprobo. Eso a menudo cambia un poco, y a veces mucho. Por ejemplo, si estoy codificando un algoritmo que está definido con precisión de antemano, o una especificación donde la implementación es "obvia", podría escribir primero los comentarios y luego el código.