Uso di spazi verticali verticali

Question

La mia intenzione in questa domanda non è di essere pedante, ma piuttosto di esplorare un asse trascurato di un argomento importante (the use of whitespace). Molta discussione e attenzione è stata posta nell'uso degli spazi bianchi orizzontali, rientranti dopo un condizionale, uno spazio tra un if e una parentesi, ecc. In effetti il ​​problema è considerato così importante e controverso che, non solo alcune aziende hanno regole e standard per questo, ma alcune aziende hanno persino delle regole che vietano la sua discussione.

Perché è, considerando lo stato degli spazi bianchi orizzontali, che la discussione sugli spazi bianchi verticali è un problema così grave? Perché lo x è più importante dello y? Qualche giorno fa ho notato che quando leggo il codice, io, senza pensare, regolare spesso i raggruppamenti verticali delle affermazioni. Avendo letto il codice di altri popoli ora, con uno sguardo verso lo spazio bianco verticale, ho notato diversi schemi, quindi chiedo stackoverflow:

• Quali regole rigide applicate a spazi vuoti verticali?
• Esistono usi di spazi verticali che sono generalmente considerati molto negativi o molto buone pratiche?
• Hai trovato che leggere il codice con spazi bianchi "corretti" ha aiutato a comprenderlo?
• Qualcuno diverso da typographers e me cura?

Answer 1

Guardo lo spazio verticale nel codice nel modo in cui guardo i paragrafi in prosa scritta.Proprio come un paragrafo è pensato per raggruppare frasi che hanno un punto o un'idea comune, le linee che sono correlate dovrebbero essere raggruppate insieme.

L'obiettivo generale è migliorare la leggibilità del codice. Proprio come un articolo senza paragrafi sarebbe difficile da leggere, quindi è un codice senza spazio verticale. E proprio come con la prosa, c'è un equilibrio tra la composizione di paragrafi che sono troppo brevi o troppo lunghi. Ma alla fine, dipende principalmente dallo stile personale e dalle preferenze.

Answer 2

Mi interessa e tendo a raggruppare il codice correttamente (almeno per i miei occhi) con righe vuote, se del caso. Spesso questo significa molte righe vuote, ma in generale considero il codice più leggibile che con tutto pieno zeppo. Proprio come gli spazi attorno agli operatori sono una cosa molto carina, così come le righe vuote attorno alle dichiarazioni raggruppate logicamente.

Più di una singola riga vuota contemporaneamente sembra un po 'fuori posto, però.

Answer 3

Trovo difficile leggere se il codice è distanziato irregolarmente verticalmente. Mi spingo fino al punto di rimuovere le parentesi graffe non necessarie, o se si tratta di blocchi brevi, come ifs o fors, posizionarlo sulla stessa riga.

Answer 4

Penso che una delle cose più importanti è quello di raggruppare un passo logico insieme, come ad esempio:

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

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

In questo modo, il codice è più facile da leggere, ed è più descrittivo, per me comunque.

Answer 5

Se un gruppo di istruzioni è correlato logicamente, gli do una riga vuota prima e dopo. Questa separazione aiuta se ho bisogno di rifattenerlo in una funzione in seguito.

Come per le doppie righe vuote: se qualcosa è distinto, dovresti davvero considerare di renderlo una funzione.

Answer 6

È noto da decenni che la capacità di un programmatore di comprendere il codice è generalmente limitata dalla quantità che può vedere in una volta. (Vedi ad esempio Weinberg, "Psicologia della programmazione di computer", un vecchio gioco ma). Ai vecchi tempi delle inserzioni cartacee, i programmatori prendevano grandi tabelle e diffondevano più pagine di annunci. Al giorno d'oggi, lo schermo immobiliare è in qualche modo migliore rispetto ai giorni di 24x80, ma tendo a minimizzare l'uso degli spazi bianchi verticali, poiché molte linee vuote occupano spazio sullo schermo che potrebbe mostrarmi codice reale.

Answer 7

Se un commento si applica a più righe di codice, quindi inserisco spazi bianchi dopo l'ultima di quelle righe, a meno che non sia c'è un'altra sintassi per interrompere le cose (come la fine di un blocco).

Ovunque io stia facendo "qualcosa" che richiede diverse righe di codice, immediatamente seguito da "qualcos'altro", quindi astraggo in funzioni separate oppure inserisco commenti [*]. Quindi le linee di codice generalmente finiscono raggruppate in blocchi brevi, eccetto dove il controllo del flusso lo rende (a mio parere) auto-esplicativo.

Mi interessa un po 'di spazio, ma in realtà sono i commenti a cui tengo di più. Se alcune righe di codice insieme fanno qualcosa di specifico, e non è stato preso come una funzione, allora mi piacerebbe vedere una descrizione inglese di cosa sia. In questo modo posso vedere che i "passaggi" della funzione si sommano veramente al risultato giusto, quindi osserviamo che ogni fase fa ciò che afferma di fare.

Nelle classi, a volte inserisco spazi tra metodi/funzioni membro e talvolta no. In C++ ho inserito spazi prima di accedere agli specificatori.

Inserisco spazi bianchi tra le classi, (a volte non per le classi interne anonime in Java) e tra funzioni esterne alle classi.

A parte questo, il mio codice è abbastanza denso verticalmente. Non utilizzo quasi mai più righe vuote, anche quando separo sezioni di un file di intestazione e simili. Preferirei blankline-commentline-blankline piuttosto che blankline-blankline, anche se il commento finisce per essere qualcosa di assolutamente banale come "funzioni di supporto". Non mi piacciono gli stili che hanno enormi spazi bianchi verticali tra le funzioni - se sono così separati che non vuoi vederli entrambi sullo schermo allo stesso tempo, direi o metterli in file diversi o riempire il vuoto con Doxygen/Commenti Javadoc.

[*] Nella versione eseguo il check-in. Di solito scrivo codice più o meno senza commenti, quindi lo compilo, eseguo test rapidi, commentalo, eseguo test appropriati, lo collaudo. Questo cambia spesso un po ', e talvolta molto. Per esempio se sto codificando su un algoritmo che è definito con precisione in anticipo, o su una specifica in cui l'implementazione è "ovvia", potrei scrivere prima i commenti e poi il codice.