¿Cómo utiliza líneas en blanco en su código?

31

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?

Matthieu M.
fuente
66
if (i % 3 != 0) { <newline here> array[i] += 2; <newline here> }, pero veo tu punto :)
Merlyn Morgan-Graham
Este tipo de preguntas no son constructivas . Solo hay tantas veces que puede reformular las dos únicas respuestas disponibles de "sí" y "no".
1
Una mejor pregunta habría sido ¿cómo y por qué usa líneas en blanco? Utilizo líneas en blanco exactamente de la misma manera que usted, con la misma motivación.
Dominique McDonnell el
1
@ Mark, @ takeshin: lo siento, olvidé el "cómo" en la palabra clave. Es obvio que todos los usamos, estaba tratando de ver cómo lo usaban las personas (separando clases, si / si no, etc.) pero parece que obtuve respuestas muy genéricas: p
Matthieu M.
3
for (int i = 0; i < 10; i += 3) { <newline here> array[i] += 2; <newline here> }pero veo tu punto :)
Berin Loritsch

Respuestas:

87

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.

Jeff Atwood
fuente
12
Puedo escuchar a alguien decir "¡pero entonces deberías extraer el método!". Un párrafo es para cuando no hay razón suficiente para extraer el Método.
Frank Shearar
1
Es fácil experimentar y ver si es mejor tener espacios en blanco verticales o no. Tome un archivo fuente desconocido para usted, elimine todas las líneas en blanco y luego intente seguir la lógica. Incluso con una sangría adecuada, será mentalmente agotador porque las líneas en blanco nos dan la oportunidad de ver cosas en trozos pequeños. Tengo que mantener un código que no usa mucho espacio en blanco vertical o sangría, por lo que agregarlo fue una de mis primeras tareas para la autoconservación.
The Tin Man
2
Estoy de acuerdo al 100% El espacio en blanco es útil cuando se usa para dividir deliberadamente código en fragmentos lógicos. Sin embargo, el espacio en blanco por el espacio en blanco es tan malo como no hay espacio en blanco. A un ex colega le gustaba poner una o más líneas en blanco después de casi cada línea de código real. Pasé una cantidad ridícula de tiempo "refactorizando" que implicaba presionar Retroceso unos miles de veces para eliminar líneas en blanco inútiles.
Mike Spross el
Agregué algunos datos para respaldar su posición. Ver: meta.programmers.stackexchange.com/questions/1109/…
Jeff Atwood
2
Esos datos no dicen nada sobre líneas en blanco, solo sobre sangría ..
Blorgbeard
21

Sí por claridad.

Justo como hice en esta respuesta.

usuario2567
fuente
13

Lo hago pero me aseguro de documentarlo poniendo

(This line intentionally left blank.)

en la línea

Don
fuente
1
Las líneas blancas con comentarios pueden llamar la atención del código
JulioC
1
Hay muchos comentarios que dicen "Esta línea se dejó en blanco intencionalmente" ... ¿No puede suponer que si una línea está en blanco, es intencional o de lo contrario no habría pasado la revisión del código?
alternativa el
43
Tal vez solo soy yo, pero supuse que el OP está bromeando ...
JSB ձոգչ
77
¿Cuánto tiempo llevas trabajando para IBM?
Guillaume
12

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.

Allon Guralnek
fuente
1
Parece algo que se usaría en un curso universitario de nivel introductorio para impulsar algunos conceptos. ¿Fue esto realmente utilizado en un entorno profesional?
rjzii
1
@Rob: Se usó en el código de producción de un sistema grande, pero sin el encabezado del comentario, y con cuerpos de métodos lo suficientemente grandes como para que la alineación me desconcertó, ya que no podía ver otras firmas de métodos en ese archivo. Cuando colapsé los cuerpos de los métodos, pude ver la "razón" del espacio en blanco.
Allon Guralnek
Eso puede funcionar en un encabezado o archivo de interfaz
Ming-Tang
Entonces, el tipo que escribió ese esquema de sangría, cuando agregó un nuevo método a una clase, y el tipo de retorno del método era más largo que cualquiera de los tipos de retorno existentes, volvería a tabular la sangría de espacios en blanco para todos los demás métodos en el ¿clase?
Mike Clark el
@ Mike, en la escuela secundaria, utilizamos un libro de programación Java (no recuerdo el título) que sabiamente aconsejaba nunca usar un espacio horizontal como este, simplemente porque termina perdiendo grandes cantidades de tiempo cuando debes hacer tales tabulaciones.
Matthew Flaschen el
5

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".

Bryan Harrington
fuente
La suposición que está haciendo es que descomprimir su código ayuda a la legibilidad, y no creo que eso sea siempre un hecho.
Jason Baker, el
Lo que dijo Jason. Cuando vuelvo a una base de código, me gusta tener tantos LOC por pantalla como sea posible para poder digerirlo rápidamente. Si alguien pone en la mitad de una página de espacios en blanco (o Dios no permita uno de esos terribles comentarios de estilo xml), estaría muy tentado a formatearlo temporalmente solo para leerlo, luego undounas pocas veces para hacer el trabajo (formateando las guerras no No conduzco a la productividad, por lo que no eliminaría por completo los comentarios y los espacios en blanco, pero mi preferencia es contra ellos en su mayor parte).
Inaimathi el
Un muro de texto es casi imposible de leer, y mucho menos la psicología humana tiende a resistirlo. Creo que también es bueno tomarse el tiempo para agrupar declaraciones similares, agrupar líneas de código que manipulan la misma variable. Supongo que todo es preferencia, pero creo que todo lo que se haga en este negocio nunca debe hacerse rápidamente.
Bryan Harrington el
5

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

Trinidad
fuente
44
A menudo también escribo hardware, luego lo imprimo. Es mucho más barato
Tim Post
55
Broma Dos Equis?
Paperjam
@Tim De hecho, no es tan divertido: impresión en 3D ;) (Y ... se amable, no todos somos hablantes nativos de inglés aquí :).
tomas
1
@takeshin No me estaba burlando de nadie, y aludía a la impresión 3D. Si bien sí, el comentario fue en broma, creo que podría estar malinterpretando la intención :) Además, el hecho de que @Paperjam comentó justo en una broma sobre la impresión es ... bueno ... no tiene precio :)
Tim Post
Yo no escribe software, pero lo cablea.
mlvljr el
5

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.

Jay Bazuzi
fuente
5

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
Nathan Long
fuente
4

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 ...

}
Jonathan Leffler
fuente
3

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.

KevBurnsJr
fuente
1
Un comentario en la parte superior que describa qué direcciones son aceptadas sería bueno. ¿Se puede realmente utilizar una expresión regular para validar una dirección de correo electrónico?
Kevin Cline
3

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.

Maniero
fuente
2

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();
}
Steve Jackson
fuente
44
Supongo que su ejemplo de Bad Whitespace es una versión abreviada de lo que debería considerarse malo. En su longitud actual, parece innecesario dividirlo.
Allon Guralnek
1
No veo por qué malo es malo ni por qué escribió VS
55
Ninguno de esos comentarios son necesarios de todos modos, y por qué en el mundo sería un extracto connection.close()acloseConnection(connection)
alternativa
Un bloque de código con un comentario es mejor que un método extraído, siempre que los bloques sean cortos y pocos. Los métodos de extracción no son gratuitos; tiene un costo de localidad de código.
Craig Gidney
Y que acaba de hacer item1y item2variables globales que los métodos se comunican a través? Ick!
TMN
2

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()
}
usuario2528
fuente
2

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.

Jason Baker
fuente
2

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é.
Wonko el cuerdo
fuente
1

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

filosodad
fuente
1

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.

Rei Miyasaka
fuente
1

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 :(

Karun AB
fuente
1

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.

revs haylem
fuente
Parece C-ish, mi estándar de codificación C ++ recomienda NO declarar un objeto sin inicializarlo, lo que impide este uso: /
Matthieu M.
@Matthieu M: OK, luego reemplace las DECLARACIONES por INICIALIZADORES. Pero nunca quiero ver INICIALES en medio de una cuadra. Si es necesario, entonces eso es algo que requiere un alcance menor, por lo que necesita un método / función privado.
haylem
0

El espacio en blanco es extremadamente valioso.

Aquí está el trato ... los nerds que escriben código complicado como E = MC 2 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 2 . 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.

Cape Cod Gunny
fuente
1
Erm ... ninguno de estos ejemplos realmente respalda tu punto. Personalmente, creo que E = MC2 es más legible que E = MC 2 (la conclusión era usar espacios en blanco, ¿verdad?). Ah, y a menos que todavía estés en la escuela secundaria, estoy seguro de que puedes encontrar una mejor manera de referirte a las personas con las que no estás de acuerdo que "nerds".
Jason Baker, el
@ Jason - Buen punto, mala elección de palabras. E = MC2 es mucho más legible, ese no era el punto que estaba tratando de transmitir. Es más como si estuvieras hablando en tu sitio web YAGNI y SYNDI. jasonmbaker.com/tag/programming
Michael Riley - AKA Gunny el
0

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.

Skudd
fuente
0

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.

usuario7187
fuente
0

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.

kirk.burleson
fuente
0

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á.

Peter
fuente
0

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).

usuario7195
fuente
2
SÍ. Quiero ver toda tu función en una pantalla. No ponga la llave de apertura en su propia línea. Para eso está la sangría.
KevBurnsJr
El objetivo de una llave en su propia línea es definir claramente bloques de código. ¡Agregar una línea de código después de la llave está arruinando la única razón por la cual se mantiene esta religión! También puede ponerlo en la misma línea que 'for'.
Gary Willoughby
0

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.

javacruiser
fuente
0

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;)

usuario7242
fuente
0

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.

FinnNk
fuente
0

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.

marca
fuente