Ci sono state alcune osservazioni sullo spazio bianco già in discussione sui posizionamenti delle parentesi graffe.

Io stesso tendo a cospargere il mio codice con righe vuote nel tentativo di separare le cose che vanno insieme in gruppi "logici" e, si spera, rendere più facile per la prossima persona leggere il codice che ho appena prodotto.

In effetti, direi di strutturare il mio codice come scrivo: faccio paragrafi, non più di alcune righe (decisamente più brevi di 10) e provo a rendere ogni paragrafo autonomo.

Per esempio:

• in una classe, raggrupperò i metodi che vanno insieme, mentre li separo da una riga vuota dal gruppo successivo.
• se devo scrivere un commento di solito inserisco una riga vuota prima del commento
• in un metodo, faccio un paragrafo per fase del processo

Tutto sommato, raramente ho più di 4/5 righe raggruppate insieme, il che significa un codice molto scarso.

Non considero tutto questo spazio bianco uno spreco perché in realtà lo uso per strutturare il codice (dato che in effetti uso il rientro), e quindi ritengo che valga la pena dello schermo.

Per esempio:

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

    array[i] += 2;
}

Ritengo che le due affermazioni abbiano chiari scopi distinti e quindi meritano di essere separate per renderlo ovvio.

Quindi, come si utilizzano (o meno) le righe vuote nel codice?

Sempre

Lo spazio bianco è fondamentale per pulire il codice leggibile. Una riga vuota (o due) aiuta a separare visivamente i blocchi logici di codice.

Ad esempio, dal Codice completo di Steve McConnell, capitolo Seconda edizione su Layout e stile:

I soggetti hanno ottenuto un punteggio dal 20 al 30 percento in più in un test di comprensione quando i programmi avevano uno schema di rientro da due a quattro spazi rispetto a quando non avevano alcun rientro.Lo stesso studio ha scoperto che era importante non sottovalutare né enfatizzare eccessivamente la struttura logica di un programma. I punteggi di comprensione più bassi sono stati raggiunti su programmi che non erano affatto rientrati. Il secondo più basso è stato raggiunto su programmi che utilizzavano il rientro di sei spazi. Lo studio ha concluso che il rientro da due a quattro spazi era ottimale. È interessante notare che molti soggetti nell'esperimento hanno ritenuto che il rientro a sei spazi fosse più facile da usare rispetto ai rientri più piccoli, anche se i loro punteggi erano inferiori. Questo è probabilmente perché sei rientri spaziali sembrano piacevoli. Ma indipendentemente da quanto sia bello, il rientro di sei spazi risulta meno leggibile. Questo è un esempio di collisione tra estetica e leggibilità.

Sì per chiarezza.

Proprio come ho fatto in questa risposta.

Lo faccio ma mi assicuro di documentarlo mettendo

(This line intentionally left blank.)

sulla linea

Sì, ma non lo abuso.

Ho visto codice in cui ogni riga di codice all'interno di un metodo è separata da una riga vuota e vengono utilizzate due righe vuote in cui si verifica una separazione logica. Questo a mio avviso lo rende ancora meno leggibile. Ho anche visto gli spazi bianchi usati per fare allineamenti folli, come questo:

//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)
{
    ...
}

Lo stesso uso improprio dello spazio bianco orizzontale può essere applicato allo spazio bianco verticale. Come qualsiasi strumento, usalo saggiamente.

Vengo molto criticato per aver scritto il mio codice in questo modo. Non capisco perché qualcuno non lo farebbe in questo modo.

La leggibilità è così importante quando torni a un progetto dopo un lungo periodo di tempo e ho sentito dire "Scrivi sempre il codice se il prossimo che lo sta leggendo è uno psicopatico che conosce la tua posizione".

Non scrivo sempre software, ma quando lo faccio, uso le righe vuote per chiarezza.

Sono tutto per rendere il codice il più chiaro possibile, e gli spazi bianchi sono spesso uno strumento utile in questa impresa. Ma non dimentichiamo il refactoring:

• in una classe, raggrupperò i metodi che vanno insieme, mentre li separo da una riga vuota dal gruppo successivo.

Poiché hai diversi membri correlati, sono candidati per una nuova classe.

• se devo scrivere un commento di solito inserisco una riga vuota prima del commento

Ogni volta che il codice non è abbastanza chiaro da volere un commento, chiedo se posso refactoring per rendere il codice abbastanza chiaro da non aver bisogno del commento.

• in un metodo, faccio un paragrafo per fase del processo

Perché non creare un metodo per ogni "paragrafo"?

Se finisci con un mucchio di metodi nella tua classe, vedi la mia nota sopra sull'estrazione di una nuova classe.

Sì. Semplifica la scansione visiva di un file. Tra le altre cose, rende più chiaro con quale linea segue un commento.

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

Uso le righe vuote con parsimonia e coerenza, e coerentemente è più importante che con parsimonia. Tuttavia:

• Se ogni riga di codice è separata dalla successiva da una riga vuota, ci sono troppe righe vuote.
• Se non c'è né rima né ragione prontamente individuabili per dove sono posizionate le righe vuote, allora sono una distrazione e di solito ce ne sono troppe.
• Se una funzione è così grande da richiedere molte righe vuote, è troppo grande.
• Se un blocco di codice ha bisogno di più di una riga vuota prima o dopo di essa, c'è qualcosa di gravemente fuori strada.
• Se ci sono più di due righe vuote tra le funzioni, probabilmente hai troppe righe vuote.

Gran parte di questo non è terribilmente controverso; ciò che segue potrebbe essere. Noto che la notazione di K&R con le parentesi graffe aperte alla fine della riga è spesso depressa, seguita da una riga vuota. Personalmente non mi piacciono le parentesi graffe alla fine della riga e mescolarle con una riga vuota dopo la parentesi graffa fa una sciocchezza della notazione (IMNSHO). Metti la parentesi graffa aperta sulla riga successiva, da sola, e hai una linea principalmente vuota (e, IMNSHO, codice più leggibile). Se è necessario utilizzare la parentesi graffa K&R alla fine della linea, non sprecare lo spazio verticale risparmiando con linee vuote estranee.

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

}

Scrivi ciò che è più leggibile e meno sorprendente.

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

Questa funzione non richiede 12 righe di commenti doc.

In realtà, non ha bisogno di commenti.

O righe vuote.

Avrebbero sminuito la sua essenza.

All'interno della funzione? Raramente

Se ho un blocco chiaramente diverso, si sta eseguendo il refactoring su una nuova funzione. Se pochi casi non ne valgono la pena.

Per me le righe vuote all'interno della funzione sono una delle "best practice" più sbagliate.

Spesso

Usalo per blocchi logici di codice che vengono elaborati in modo simile. Dopo aver aggiunto un commento per dimostrare che stai facendo un passaggio diverso, è tempo di estrarre il metodo.

Good Whitespace

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

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

    setPosition(x, y);
}

Spazi vuoti

{
    //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();
}

Non solo uso gli spazi bianchi, ma uso le parentesi graffe per maggiore chiarezza.

Le parentesi che uso per dire che possono potenzialmente essere funzioni.

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

    code()
    code()
}

Un tempo, cospargevo liberamente le righe vuote in tutto il mio codice. Oggi tendo ad essere più parsimonioso. Penso che questo sia parte di ciò di cui Steve Yegge stava parlando qui :

Spero che la scena che ho dipinto finora ti aiuti a capire perché a volte guardi il codice e lo odi immediatamente. Se sei un n00b, guarderai il codice con esperienza e dirai che è una merda impenetrabile e indisciplinata scritta da qualcuno che non ha mai imparato gli elementi essenziali della moderna ingegneria del software. Se sei un veterano, guarderai il codice n00b e dirai che è una lanugine ornamentale troppo commentata che un tirocinante avrebbe potuto scrivere in una sola notte di bevute pesanti.

Il punto critico è la tolleranza alla compressione. Mentre scrivi il codice durante la tua carriera, specialmente se si tratta di codice che si estende su lingue e domini problematici molto diversi, la tua tolleranza per la compressione del codice aumenta. Non è diverso dalla progressione dalla lettura di libri per bambini con testi giganti a romanzi sempre più complessi con testi più piccoli e parole più grandi.

...

Un programmatore con un'alta tolleranza per la compressione è in realtà ostacolato da uno schermo di narrazione. Perché? Perché per capire una base di codice devi essere in grado di comprimere il più possibile nella tua testa. Se si tratta di un algoritmo complicato, un programmatore veterano vuole vedere tutto sullo schermo, il che significa ridurre il numero di righe vuote e commenti incorporati, in particolare i commenti che semplicemente ribadiscono ciò che il codice sta facendo. Questo è esattamente l'opposto di ciò che vuole un programmatore n00b. Gli n00bs vogliono concentrarsi su una frase o espressione alla volta, spostando tutto il codice da esso in modo che possano concentrarsi, piangere ad alta voce.

Sono fondamentalmente d'accordo con lui. È molto meglio comprimere il codice in modo da poterne ottenere il più possibile su uno schermo piuttosto che spaziarlo troppo. Questo non vuol dire che non dovresti mai usare le righe vuote. È solo che penso che a meno che il raggruppamento che stai cercando di creare non aumenti immensamente la leggibilità, faccia più male che bene.

Un professore emerito ha dato due grandi consigli

1. Whitespace è gratuito
2. Non usare le graffette che risalgono attraverso la parte anteriore del foglio, altrimenti ti mancherò.

Le mie regole pratiche sono queste:

1. Se ho difficoltà a leggere il codice che ho scritto ieri, probabilmente ho bisogno di estrarre un metodo o tre.

2. Se la definizione della mia classe è troppo lunga per essere letta facilmente, probabilmente ho bisogno di estrarre un modulo / interfaccia / oggetto.

3. Definizioni del metodo: aggiungere una riga

4. Definizioni modulo / classe: aggiungere due righe

Mi piace pensare agli spazi bianchi allo stesso modo del paragrafo. Raggruppate linee che contribuiscono a un'idea.

Se stai iniziando una nuova idea o un nuovo aspetto della stessa idea, inizi un nuovo paragrafo, come questo.

Nel codice imperativo, raggruppo i compiti che svolgono un compito coeso; nel codice dichiarativo, raggruppo il codice che descrive un'affermazione coerente di un'idea.

Chiaramente non hai problemi a farlo in inglese (alcune persone sono orribili con i paragrafi), quindi con un po 'di pratica, applicare la stessa abilità al codice non dovrebbe essere affatto estensivo.

Le righe vuote sono un must secondo me. Li uso per separare diversi blocchi logici di codice. Rende leggibile il codice. Il codice leggibile è un buon codice;)

Il mio pezzo di codice ideale sarebbe ogni blocco logico separato da una riga vuota e un commento sopra ogni blocco che ha una logica maggiore.

Certo, se le persone lo fanno aggiungendo più righe vuote ovunque, lo trovo molto irritante :(

Uso solo spazi bianchi all'interno di una funzione / metodo per separare dichiarazioni e codice.

Se senti la necessità di avere alcune righe per separare i blocchi secondari di codice che implementano della logica, allora dovrebbero trovarsi in un'altra funzione / metodo privato. Spetta al tuo compilatore non fare un sovraccarico troppo grande.

in genere, nel codice peusdo:

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

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Se vedo spazi bianchi inutili, di solito mi rabbrividisco.

Lo spazio bianco è estremamente prezioso.

Ecco il problema ... I nerd che scrivono codice complicato come E = MC ² sono bravissimi a mostrare le loro capacità di programmazione.

Ora facciamo un salto in avanti di sei mesi, e sono le 2:00 del mattino e il sistema che non è stato esaminato da sei mesi si è rotto proprio sulla linea di E = MC ² . È quasi impossibile eseguire il debug ... tutti stanno andando fuori di testa.

Supponiamo che il codice assomigli di più a questo ...

See Dick
See Jane
See Dick and Jan

Se sono le 2:00 del mattino e il codice è rotto. Una rapida occhiata ti mostrerà che la terza riga avrebbe dovuto essere

See Dick and Jane

Problema risolto.

Bottom Line ... usa gli spazi bianchi.

Come molti altri hanno affermato, le righe vuote facilitano la lettura del codice. Tuttavia, ci sono alcune lingue che applicano questo standard. Uno che mi viene in mente dalla parte superiore della mia testa (non tanto sulle righe vuote ma sul rientro corretto) è Python.

Sono d'accordo, utilizzo gli spazi bianchi allo stesso modo. Tuttavia, se mi ritrovo a utilizzare gli spazi bianchi per suddividere un metodo in troppe parti, è un segno che potrebbe essere necessario riformattare quel codice in più metodi. Troppe sezioni logiche in un metodo potrebbero segnalare che il metodo sarà più difficile da testare.

Li uso per separare il codice in unità logiche. Ho visto pochissimi esempi di codice che non utilizzavano righe vuote, ovviamente l'offuscamento è escluso.

La risposta di Psychopath è la migliore, ma la sostituirei supponendo che la persona successiva sia un idiota e che presumeranno che tu lo sia, e vorrai dimostrare che si sbagliano.

Altrettanto importante per la leggibilità è l'uso dei commenti. Apro ogni funzione o subroutine con un blocco di commenti, spiegando in chiaro, cosa è, cosa fa, quali sono gli argomenti e quali sono i risultati attesi (incluso un elenco di condizioni di errore). Quindi non c'è dubbio su ciò che è destinato e / o progettato per fare. Ciò che raggiunge può variare, ma è più in basso.

Penso che troppi programmatori credano che saranno loro stessi a fare "riparazioni" sul codice o semplicemente non se ne cureranno.

Le righe vuote sono importanti. Tuttavia, sprecare un'intera riga vuota sulla parentesi graffa di apertura riduce la quantità di codice che è possibile visualizzare in una schermata. Dovrebbe essere:

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

   array[i] += 2;
}

(Non farmi iniziare a mettere la parentesi graffa "{" sulla stessa riga di "for" ... che è meshuggah).

Sì. Per leggibilità. A volte inserisco persino righe vuote nel codice che non ho scritto. Trovo più facile capire il codice quando hanno un raggruppamento logico tramite righe vuote, come se tu potessi "leggere velocemente" attraverso di esso.

Dovremmo usare le righe vuote tra i blocchi di codice come facciamo quando scriviamo una lettera.

Ad esempio, tra le funzioni o all'interno di una funzione quando finiamo un ciclo ...

Le persone ti ringrazieranno di un codice pulito se devono fare manutenzione su di esso;)

Utilizziamo lo spazio bianco consigliato da Microsoft StyleCop. A parte la leggibilità e la coerenza, ho scoperto che (insieme a classi di dimensioni ridotte) un codice correttamente strutturato semplifica notevolmente la gestione delle fusioni quando varie persone di una squadra lavorano nelle stesse aree.

Non sono sicuro che sia solo la mia immaginazione, ma strumenti diversi sembrano fare un lavoro migliore nel riconoscere dove inizia e finisce il codice equivalente quando si fondono quando sono disposte in modo ordinato. Il codice ben strutturato è una gioia da unire. Ok, quella era una bugia - ma almeno il dolore è mantenuto a livelli gestibili.

Mai una riga vuota, non nell'intero file. Questo non vuol dire che non ci sono interruzioni nel codice:

 code;
 //
 morecode;

Le righe vuote servono per aprire sezioni del codice su cui lavorare, hai un paio di tasti di scelta rapida nel tuo editor per portarti alla riga vuota precedente / successiva.