Ha habido algunos comentarios sobre el espacio en blanco ya en discusión sobre la colocación de llaves.

Yo mismo tiendo a rociar mi código con líneas en blanco en un intento de segregar cosas que van juntas en grupos "lógicos" y espero que sea más fácil para la próxima persona que lea el código que acabo de producir.

De hecho, diría que estructuro mi código como lo escribo: hago párrafos, no más de unas pocas líneas (definitivamente más cortas que 10), y trato de hacer que cada párrafo sea autónomo.

Por ejemplo:

• en una clase, agruparé métodos que van juntos, mientras los separo por una línea en blanco del siguiente grupo.
• si necesito escribir un comentario, generalmente pondré una línea en blanco antes del comentario
• en un método, hago un párrafo por paso del proceso

Con todo, rara vez tengo más de 4/5 líneas agrupadas, lo que significa un código muy escaso.

No considero que todo este espacio en blanco sea un desperdicio porque en realidad lo uso para estructurar el código (ya que de hecho uso la sangría) y, por lo tanto, creo que vale la pena el estado de la pantalla que requiere.

Por ejemplo:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Considero que las dos declaraciones tienen claros propósitos distintos y, por lo tanto, merecen separarse para que sea obvio.

Entonces, ¿cómo usas (o no) líneas en blanco en el código?

Siempre

El espacio en blanco es crucial para limpiar el código legible. Una línea en blanco (o dos) ayuda a separar visualmente los bloques lógicos de código.

Por ejemplo, del capítulo Completo de Steve McConnell, Segunda edición sobre Diseño y estilo:

Los sujetos obtuvieron un puntaje de 20 a 30 por ciento más alto en una prueba de comprensión cuando los programas tenían un esquema de sangría de dos a cuatro espacios que cuando los programas no tenían sangría en absoluto.El mismo estudio encontró que era importante no enfatizar ni enfatizar demasiado la estructura lógica de un programa. Los puntajes de comprensión más bajos se lograron en programas que no tenían sangría en absoluto. Los segundos más bajos se lograron en programas que usaban sangría de seis espacios. El estudio concluyó que la sangría de dos a cuatro espacios era óptima. Curiosamente, muchos sujetos en el experimento sintieron que la sangría de seis espacios era más fácil de usar que las sangrías más pequeñas, a pesar de que sus puntajes eran más bajos. Eso es probablemente porque seis sangría espacial parece agradable. Pero independientemente de lo bonita que se vea, la sangría de seis espacios resulta menos legible. Este es un ejemplo de colisión entre atractivo estético y legibilidad.

Sí por claridad.

Justo como hice en esta respuesta.

Lo hago pero me aseguro de documentarlo poniendo

(This line intentionally left blank.)

en la línea

Sí, pero no abuso de eso.

He visto código donde cada línea de código dentro de un método está separada por una línea en blanco, y se usan dos líneas en blanco donde se produce una separación lógica. Eso solo lo hace aún menos legible en mi opinión. También he visto espacios en blanco utilizados para hacer alineaciones locas, como esta:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

El mismo mal uso del espacio en blanco horizontal se puede aplicar al espacio en blanco vertical. Como cualquier herramienta, úsala sabiamente.

Me critican mucho por escribir mi código de esta manera. No entiendo por qué alguien no lo haría de esta manera.

La legibilidad es muy importante cuando vuelves a un proyecto después de un período prolongado de tiempo y escucho un dicho "Siempre escribe el código si el siguiente tipo que lo está leyendo es un psicópata que conoce tu ubicación".

No siempre escribo software, pero cuando lo hago, uso líneas en blanco para mayor claridad.

Estoy a favor de que el código sea lo más claro posible, y el espacio en blanco a menudo es una herramienta útil en ese esfuerzo. Pero no olvidemos refactorizar:

• en una clase, agruparé métodos que van juntos, mientras los separo por una línea en blanco del siguiente grupo.

Como tiene varios miembros relacionados, son candidatos para una nueva clase.

• si necesito escribir un comentario, generalmente pondré una línea en blanco antes del comentario

Cada vez que el código no es lo suficientemente claro como para querer un comentario, le pregunto si puedo refactorizar para que el código sea lo suficientemente claro como para no necesitar el comentario.

• en un método, hago un párrafo por paso del proceso

¿Por qué no hacer un método para cada "párrafo"?

Si terminas con un montón de métodos en tu clase, mira mi nota anterior sobre cómo extraer una nueva clase.

Sí. Facilita el escaneo visual de un archivo. Entre otras cosas, aclara con qué línea va un comentario.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

Utilizo líneas en blanco con moderación y coherencia, y consistentemente es más importante que con moderación. Sin embargo:

• Si cada línea de código está separada de la siguiente por una línea en blanco, hay demasiadas líneas en blanco.
• Si no hay ni rima ni razón fácilmente discernibles sobre dónde se colocan las líneas en blanco, entonces son una distracción y generalmente hay demasiadas.
• Si una función es tan grande que necesita muchas líneas en blanco, es demasiado grande.
• Si un bloque de código necesita más de una línea en blanco antes o después, hay algo seriamente perdido.
• Si tiene más de dos líneas en blanco entre funciones, probablemente tenga demasiadas líneas en blanco.

La mayor parte de eso no es terriblemente controvertido; lo que sigue podría ser. Observo que la notación K&R con los corchetes abiertos al final de la línea a menudo es deprimentemente seguida de una línea en blanco. Personalmente, no me gustan los corchetes al final de la línea y mezclarlos con una línea en blanco después de que el corchete no tiene sentido de la notación (IMNSHO). Coloque la llave abierta en la siguiente línea, por sí sola, y tendrá una línea en su mayoría en blanco (y, IMNSHO, un código más legible). Si debe usar una llave K&R al final de la línea, no desperdicie el ahorro de espacio vertical con líneas en blanco extrañas.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Escribe lo que sea más legible y menos sorprendente.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Esta función no necesita 12 líneas de comentarios de documentos.

De hecho, no necesita ningún comentario.

O líneas en blanco.

Le restarían valor a su esencia.

Dentro de la función? Raramente

Si tengo un bloque claro diferente, se refactoriza a una nueva función. Si pocos casos no valen la pena.

Para mí, las líneas en blanco dentro de la función es una de las "mejores prácticas" más incorrectas.

A menudo

Úselo para bloques lógicos de código que se procesan de manera similar. Una vez que agregue un comentario para mostrar que está haciendo un paso diferente, es hora de extraer el Método.

Buen espacio en blanco

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Espacio en blanco malo

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

No solo uso espacios en blanco, también uso llaves para mayor claridad.

Las llaves que uso para decir que estas pueden ser funciones.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

Hubo un tiempo en que esparcía líneas en blanco generosamente a lo largo de mi código. Hoy en día, tiendo a ser más moderado. Creo que esto es parte de lo que Steve Yegge estaba hablando aquí :

Esperemos que la escena que he pintado hasta ahora te ayude a entender por qué a veces miras el código y simplemente lo odias de inmediato. Si eres un n00b, verás un código experimentado y dirás que es una basura impenetrable e indisciplinada escrita por alguien que nunca aprendió lo esencial de la ingeniería de software moderna. Si eres un veterano, verás el código n00b y dirás que es una pelusa ornamental demasiado comentada que un pasante podría haber escrito en una sola noche de consumo excesivo de alcohol.

El punto de fricción es la tolerancia a la compresión. A medida que escribe código a lo largo de su carrera, especialmente si es un código que abarca idiomas muy diferentes y dominios problemáticos, aumenta su tolerancia a la compresión de código. No es diferente de la progresión de leer libros para niños con texto gigante a novelas cada vez más complejas con texto más pequeño y palabras más grandes.

...

Un programador con una alta tolerancia a la compresión en realidad se ve obstaculizado por una gran cantidad de historias. ¿Por qué? Porque para comprender una base de código, debe poder empacar la mayor cantidad posible en su cabeza. Si se trata de un algoritmo complicado, un programador veterano quiere ver todo en la pantalla, lo que significa reducir la cantidad de líneas en blanco y comentarios en línea, especialmente comentarios que simplemente reiteran lo que está haciendo el código. Esto es exactamente lo contrario de lo que quiere un programador n00b. Los n00bs quieren enfocarse en una declaración o expresión a la vez, quitando todo el código a su alrededor para que puedan concentrarse y llorar en voz alta.

Estoy fundamentalmente de acuerdo con él. Es mucho mejor comprimir el código para que pueda obtener la mayor cantidad posible en una pantalla que espaciarlo demasiado. Eso no quiere decir que nunca debas usar líneas en blanco. Es solo que creo que, a menos que la agrupación que intentas crear no aumente enormemente la legibilidad, hace más daño que bien.

Un profesor emérito dio dos grandes consejos

1. El espacio en blanco es gratis
2. No uses las grapas que vuelven a pasar por el frente del papel, o te fallaré.

Mis reglas generales son estas:

1. Si tengo problemas para leer el código que escribí ayer, probablemente necesito extraer un método o tres.

2. Si mi definición de clase es demasiado larga para leerla fácilmente, probablemente necesite extraer un módulo / interfaz / objeto.

3. Definiciones de métodos: agregar una línea

4. Definiciones de módulo / clase: agregue dos líneas

Me gusta pensar en espacios en blanco de la misma manera que en los párrafos. Agrupa líneas que contribuyen a una idea.

Si está comenzando una nueva idea o una nueva faceta de la misma idea, comienza un nuevo párrafo, como este.

En código imperativo, agrupo tareas que realizan una tarea cohesiva; en el código declarativo, agrupo el código que describe una declaración coherente de una idea.

Claramente, no tiene problemas para hacerlo en inglés (algunas personas son horribles con los párrafos), por lo que con un poco de práctica, aplicar la misma habilidad al código no debería ser estresante.

Las líneas en blanco son imprescindibles en mi opinión. Los uso para separar diferentes bloques lógicos de código. Hace que el código sea legible. El código legible es un buen código;)

Mi código ideal sería que cada bloque lógico esté separado por una línea en blanco y un comentario en la parte superior de cada bloque que tenga una lógica principal.

Por supuesto, si las personas lo hacen agregando múltiples líneas en blanco en todas partes, me resulta muy irritante :(

Solo uso espacios en blanco dentro de una función / método para separar las declaraciones y el código.

Si siente la necesidad de tener algunas líneas para separar subbloques de código que implementan alguna lógica, entonces deberían estar en otra función / método privado. Depende de su compilador no hacer que esa carga sea demasiado grande.

típicamente, en código peusdo:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Si veo espacios en blanco inútiles, generalmente me estremezco.

El espacio en blanco es extremadamente valioso.

Aquí está el trato ... los nerds que escriben código complicado como E = MC ² son excelentes para mostrar sus habilidades de programación.

Ahora avancemos seis meses, y son las 2:00 a.m. de la mañana y el sistema que no se ha visto en seis meses se ha roto en la línea misma de E = MC ² . Esto es casi imposible de depurar ... todos se están volviendo locos.

Supongamos que el código se parece más a esto ...

See Dick
See Jane
See Dick and Jan

Si son las 2:00 a.m. y el código está roto. Un vistazo rápido le mostrará que la línea tres debería haber sido

See Dick and Jane

Problema resuelto.

En pocas palabras ... use espacios en blanco.

Como muchos otros han dicho, las líneas en blanco facilitan la lectura del código. Sin embargo, hay algunos idiomas que hacen cumplir este estándar. Uno que se me ocurre en la parte superior de mi cabeza (no tanto sobre líneas en blanco sino sobre sangría adecuada) es Python.

Estoy de acuerdo, uso espacios en blanco de la misma manera. Sin embargo, si me encuentro usando espacios en blanco para dividir un método en demasiadas partes, es una señal de que podría necesitar refactorizar ese código en varios métodos. Demasiadas secciones lógicas en un método pueden indicar que el método será más difícil de probar.

Los uso para separar el código en unidades lógicas. He visto muy pocos ejemplos de código que no utilizan líneas en blanco, por supuesto, se ofusca la ofuscación.

La respuesta del psicópata es la mejor, pero la reemplazaría suponiendo que la próxima persona es una idiota, y que asumirán que lo eres y querrás demostrar que están equivocados.

Igual de importante para la legibilidad es el uso de comentarios. Abro cada función o subrutina con un bloque de comentarios, explicando en texto claro, qué es, qué hace, cuáles son los argumentos y cuáles son los resultados esperados (incluida una lista de condiciones de error). Entonces no hay duda de para qué está destinado y / o diseñado. Lo que logra puede variar, pero eso está más adelante.

Creo que demasiados codificadores asumen que serán ellos, ellos mismos los que harán "reparaciones" en el código, o simplemente no les importará.

Las líneas en blanco son importantes. Sin embargo, desperdiciar toda una línea en blanco en la llave de apertura reduce la cantidad de código que puede ver en una pantalla completa. Debiera ser:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(No me hagas empezar a poner la llave '{' en la misma línea que 'for' ... eso es meshuggah).

Sí. Por legibilidad. A veces incluso pongo líneas en blanco en el código que no escribí. Me resulta más fácil entender el código cuando tienen agrupación lógica a través de líneas en blanco, como si pudieras "leer rápidamente" a través de él.

Deberíamos usar líneas en blanco entre los bloques de código como lo hacemos cuando escribimos una carta.

Por ejemplo, entre funciones, o dentro de una función cuando terminamos un ciclo ...

La gente le agradecerá un código limpio si tiene que hacer mantenimiento en él;)

Utilizamos el espacio en blanco recomendado por Microsoft StyleCop. Además de la legibilidad y la coherencia, descubrí que (junto con los tamaños de clase pequeños) el código correctamente establecido hace que sea mucho más fácil administrar las fusiones cuando varias personas de un equipo trabajan en las mismas áreas.

No estoy seguro de si es solo mi imaginación, pero las diferentes herramientas parecen hacer un mejor trabajo al reconocer dónde comienza y termina el código equivalente cuando se combina cuando se presenta de manera ordenada. El código bien diseñado es una alegría para combinar. Ok, eso fue una mentira, pero al menos el dolor se mantiene a niveles manejables.

Nunca una línea en blanco, no en todo el archivo. Eso no quiere decir que no haya interrupciones en el código:

 code;
 //
 morecode;

Las líneas en blanco son para abrir secciones del código para trabajar, tiene un par de teclas de acceso rápido en su editor para llevarlo a la línea en blanco anterior / siguiente.