Lo spazio bianco è troppo brutto? [chiuso]

Ci sono due ragioni per le quali dovresti considerare strongmente di non fare questo:

1. Il codice è molto più difficile da capire quando non puoi vedere tutte le parti rilevanti contemporaneamente. Inserendo una linea vuota tra la maggior parte delle linee, stai dimezzando la quantità di codice che puoi vedere.

2. La coerenza con il codice di altre persone è importante nei progetti di gruppo. Non importa troppo quali convenzioni particolari il progetto segue finché è coerente. È abbastanza difficile capire i grandi sistemi; è ancora più difficile quando ogni parte ha schemi di indentazione diversi, convenzioni di denominazione e idiomi.

Lo spazio bianco è davvero utile aiuta a suddividere sezioni di testo per rendere più distinte le varie parti e si distingue "questo è un blocco. Guardalo in quel contesto".

Lo spazio bianco orizzontale è utilizzato per la rientranza e lo scope per dare anche suggerimenti. Uno dei pericoli del mettere troppo spazio bianco verticale è che l'occhio perde la capacità di tracciare il rientro. Nelle lingue senza {} , questo può essere disastroso per il contesto del codice.

Questo contesto è molto importante. Se qualcosa non è visualizzato sullo schermo, non è possibile eseguire rapidamente la scansione su di esso - è necessario scorrere fino ad esso. Ciò può significare perdere il codice che stavi guardando e dover spostare la mano sul mouse. Queste cose richiedono tempo e un po 'di energia mentale. Mentre può essere una piccola quantità di energia mentale, è ancora un dispendio inutile.

In realtà guardiamo questo e prendiamo del codice. Si tratta di _header_value_parser.py

Il testo non ha importanza, ma nota che questo è un po 'meno sullo schermo. Non si può nemmeno ottenere il metodo completo nella pagina. E ci sono domande su dove si allineano alcuni dei blocchi - l'occhio non viaggia così bene mantenendo le cose in fila fino a lontano (diventa più ovvio nel grande dimensione immagine - la linea 176 si allinea con lo scope di 135 o 133?).

Non si tratta di quante linee si sta verificando (qualsiasi metrica di controllo del codice di conteggio sta usando linee di codice sorgente invece che sconti spazio bianco e può anche scontare linee di commento). Si tratta di mantenere le cose in una facile distanza di scambio dell'occhio e della mente.

Is too much whitespace a bad thing?

Chiaramente: Sì. Se dici, è troppo, allora è un segno, perché qualcosa di puzzolente sta succedendo.

I often add a line break almost after every line and large blocks of whitespace, often 3 or 4 lines because it helps me see what I've written and understand what I've written when I look back on it at a later time. I also think it just looks cleaner.

Il tuo problema non è uno spazio bianco, il tuo problema è clean code o superiore: una mancanza di codice pulito.

Un codice clean lezione ci insegna: abbattere blocchi di codice di grandi dimensioni in blocchi più piccoli. Scommetto che ogni blocco che avvolgi in whitespache è un blocco, che potrebbe essere ridotto in piccoli pezzi a portata di mano.

Provalo con paranoia: ogni funzione superiore a 10 righe deve essere suddivisa in blocchi più piccoli. E nel caso in cui stai scrivendo OO: ogni classe più lunga di 200 righe è troppo grande.

Ovviamente 10/200 linee è un numero arbitrario, ma se segui questa regola per un po ', noterai gli effetti: a) non avrai più blocchi bianchi b) il tuo codice diventerà più compatto, leggibile e meglio da capire, e alla fine: mantenibile.

Although I can see two issues with this, 1) It can increase the file size of the source files, even just a line break every two or three lines can add up in a long file. I know that a good compiler will optimize all the white space out (I'm not actually sure, I think LLVM/Clang does this) but the source file is still large.

Perché preoccuparsi della dimensione dei file? Non viviamo negli anni '80 e immagazziniamo tutto su nastro. Siamo nell'età di Big Data . Questa è la preoccupazione sbagliata. E se dividi i blocchi in blocchi leggibili, il numero di file e le dimensioni aumenteranno. Ma non preoccuparti.

And 2) it may cause some people to think I'm embellishing my code to make it look longer and "bigger" to make others think I'm doing more work than I actually am (consider 3000 lines vs. 6000 lines, 3000 being newlines). Which I am not doing that by the way. Is using too much whitespace bad from a technical standpoint and/or a professional standpoint?

Anche questa è una preoccupazione sbagliata. Se sei misurato dal LoC o dal byte dell'output, esci dal lavoro. Il codice dovrebbe essere misurato in termini di qualità e quantità.

Raccomando le Guide di stile di Google per il linguaggio di programmazione che stai utilizzando. Mi attengo a queste regole e di solito portano a un codice dall'aspetto pulito. Ci sono qualcosa che mi aggiungo (come 2 righe vuote tra le funzioni) ma nel complesso mi piacciono molto le Guide di stile di Google .

Aggiornamento:

Le diverse guide di stile variano un po 'per lingua, poiché vengono assemblate da diversi ingegneri che dedicano tutto il loro tempo a lavorare in quel linguaggio, quindi ciò che hanno scritto è ciò che credono porta a un codice dall'aspetto pulito. Sembra che, in generale, la regola empirica sia di utilizzare solo righe vuote per distinguere i gruppi di codici. Più linee vuote consecutivi non vengono quasi mai incoraggiate. Ecco alcuni estratti da queste guide:

Java

Viene visualizzata una singola riga vuota:

1. Tra membri consecutivi (o inizializzatori) di una classe: campi, costruttori,   metodi, classi annidate, inizializzatori statici, inizializzatori di istanze.   
   • Eccezione: una linea vuota tra due consecutivi     i campi (non avendo altro codice tra loro) è facoltativo. Tali righe vuote vengono utilizzate secondo necessità     crea raggruppamenti logici di campi.
2. All'interno dei corpi dei metodi, come necessario per creare raggruppamenti logici di istruzioni.
3. Facoltativamente prima del primo membro o dopo l'ultimo membro della classe (nessuno dei due   incoraggiato o scoraggiato).
4. Come richiesto da altre sezioni di questo documento (come la Sezione 3.3,   Importa istruzioni).

Più righe vuote consecutivi sono consentite, ma mai richieste (o incoraggiate).

Python

Due righe vuote tra definizioni di primo livello, siano esse definizioni di funzioni o di classi. Una riga vuota tra le definizioni del metodo e tra la riga di classe e il primo metodo. Usa singole righe vuote come ritieni opportuno all'interno di funzioni o metodi.

C ++

Riduci al minimo l'utilizzo degli spazi bianchi verticali.

Questo è più un principio che una regola: non usare righe vuote quando non è necessario. In particolare, non mettere più di una o due righe vuote tra le funzioni, resistere alle funzioni iniziali con una riga vuota, non terminare le funzioni con una riga vuota e discriminare con l'uso di righe vuote all'interno delle funzioni.

Il principio di base è: più codice si adatta a uno schermo, più facile è seguire e comprendere il flusso di controllo del programma. Naturalmente, la leggibilità può risentire del fatto che il codice è troppo denso e troppo diffuso, quindi usa il tuo giudizio. Ma in generale, minimizza l'uso degli spazi bianchi verticali.

Alcune regole pratiche per aiutare quando le righe vuote possono essere utili:

• Le righe vuote all'inizio o alla fine di una funzione aiutano molto raramente la leggibilità.
• Le righe vuote all'interno di una catena di blocchi if-else possono aiutare a migliorare la leggibilità

Objective-C

Le righe vuote prima e dopo @interface, @implementation e @end sono opzionali. Se @interface dichiara le variabili di istanza, una riga vuota dovrebbe venire dopo la parentesi di chiusura (}).

A meno che un'interfaccia o un'implementazione siano molto brevi, come quando si dichiarano una manciata di metodi privati o una classe bridge, l'aggiunta di righe vuote di solito aiuta la leggibilità.
Inserisco qui solo le informazioni sugli spazi bianchi verticali, ma alcune guide hanno anche informazioni sugli spazi bianchi orizzontali e molte più informazioni di formattazione (commenti, blocchi, rientri, ecc ...)
E il progetto è open source quindi se hai qualche suggerimento potresti mandare un'email a uno dei proprietari del progetto.

Dipende da cosa intendi per troppa spazio. Per me è importante e primordiale usare lo spazio per migliorare la leggibilità del tuo codice. Usa una riga libera per separare pochi blocchi in funzione, lo spazio libero tra la funzione e la classe è buono, e il simbolo di allinea con poche lingue può essere bello anche:

sub my_function {
     my $arg = @_;

     my $a       = 42;
     my $b       = 50;
     my $sum     = $a + $b;

     my $map = {
         key         => 'value',
         second => 'second value'
     }

     if ( $sum > $ arg ) {
         return $sum
     }

     return;
}

Un piccolo esempio di ciò che amo, anche se usi anche il mio spazio di linea non è buono. Per esempio cinque linee libere tra l'ultimo ritorno e la struttura condizionale, per me è una cattiva idea.

Oltre alle altre buone risposte, ci sono anche problemi con gli strumenti. I buoni editor di testo forniranno servizi (come l'evidenziazione) per abbinare le parentesi di apertura e chiusura. Ma alcuni di loro, come Gedit, non lo faranno quando sono troppo lontani. Ovviamente vuol dire che dovresti anche evitare i metodi lunghi, ma anche troppi vuoti verticali possono anche danneggiare.

Le righe vuote possono essere utili per facilitare la lettura di un programma se vengono utilizzate per separare blocchi logici (come i paragrafi di un testo). Se tutto è separato è come se nulla fosse.

Puoi avere troppo spazio bianco - di solito è fastidioso vedere una linea vuota tra il blocco e la parentesi graffa finale, ad esempio:

if (x)
{
    // do something

    // do more


}

Questo mi infastidisce molto Ma poi, mi piacciono più righe vuote tra le funzioni: 1 riga è sufficiente per i blocchi logici all'interno di una funzione, quindi 2 rende ogni funzione spicca un po 'di più.

All'interno delle funzioni, non si desidera spaziarlo così tanto da sembrare che i blocchi logici al suo interno siano funzioni stesse. Stai cercando di suddividere un grande blocco di testo in modo che sia facile da leggere (come i paragrafi di un libro) senza introdurre un bianco estraneo che inizi a disturbare la capacità del lettore di raggruppare questi blocchi.

Quindi: uno standard rapido per te: 1. rientro corretto. 2. singola riga vuota tra i blocchi, se del caso 3. più righe vuote tra le funzioni. 4. da nessuna parte altro.

Aderisci a questo e avrai colleghi felici e codice in ordine.

Dipende sicuramente dai vari fattori citati da altri.

Ci sono alcune circostanze in cui desidero più spazi bianchi, ad es. Preferirei

class Thing

  def method1
    stuff
  end

  def method2
    stuff
  end

end

a

class Thing
  def method1
    stuff
  end
  def method2
    stuff
  end
end

perché se quei metodi diventano lunghi, avere le linee whtespace tra loro è utile.

Quindi, come linea guida generale per il codice, per% di linee di spazi bianchi, dovrei cercare una cifra compresa tra il 10% e il 30%. Meno di questo e hai lunghi algoritmi, oltre a questo e potresti scorrere su e giù e perdere il contesto e il raggruppamento visivo "vedi insieme".

Tuttavia, questo ha detto ...

per alcuni usi, avere "tutto su uno schermo" è davvero utile.

Un buon esempio se il mio file .bashrc che aveva ottenuto 3 o 4 "schermate" valesse un altro:

• duplicazione per le stesse impostazioni
• usi in conflitto delle stesse impostazioni
• dimenticando le impostazioni

Quindi, in questo caso, ho fatto un grande sforzo per "comprenderlo". In questo caso, non solo gli spazi bianchi ma i costrutti if then si adattano a 1 riga, ad es.

test -f ~/.bash_aliases && . $_

ed è stato in grado di ridurlo a 27 righe che posso vedere tutto in una volta, anche in una piccola finestra di terminale, cioè

Infine, i due problemi che hai menzionato - la dimensione del file e la lunghezza del padding non sono fattori a cui tutti i programmatori che conosco e rispettano avrebbero prestato attenzione - ricorda che 100 GB sono centomila milioni di byte. Gli spazi di linea supplementari saranno considerati come la preferenza per lo spazio di linea. Se il codice funzionasse effettivamente, questo sarebbe di solito un problema relativamente minore, anche se con una squadra, su cui dovrebbe essere concordato.

Quando si tratta di spazi bianchi, le dimensioni dei file e le prestazioni di compilazione non dovrebbero essere di alcun interesse, e gli spazi bianchi non dovrebbero avere alcun effetto sull'output del compilatore.

Si tratta di leggibilità, ma la leggibilità di un dato campione sarà diversa per i diversi lettori.

Come è stato affermato in altre risposte, troppo spazio verticale verticale ha l'effetto di sollevare frammenti di codice dal contesto, il che può compromettere la comprensione quando tale contesto è necessario per una corretta comprensione. Generalmente non separerò mai nulla da più di una riga vuota - abbastanza da far partire un po 'di codice senza sacrificare il contesto. Ho lavorato con uno sviluppatore che ha insistito su quattro righe vuote tra le funzioni. Lo ha trovato utile per la leggibilità, ho ritenuto eccessivo, non ha contribuito alla leggibilità e ha ostacolato la navigazione.

Se lavori in un team, dovresti avere una guida di stile e lavorare su questo (se fatto in casa o qualcosa di più ampiamente distribuito); presumibilmente ospiterà la maggior parte dei lettori che dovranno lavorare con quel codice.

Gli spazi bianchi nel codice possono essere usati per creare enfasi, una riga vuota prima e dopo un blocco di codice può essere usato per indicare che il codice nel blocco è un po 'più vicino a se stesso che al codice circostante. Se metti una linea vuota tra ogni riga di codice che ti sei impedito di usare questo metodo di enfasi, quindi usi più righe vuote dove hai bisogno di questa enfasi. Non hai guadagnato nulla in termini di enfasi, hai appena guadagnato un sacco di righe vuote.

Pensi che il tuo codice sia più pulito. La cosa divertente dello stato dell'essere pulito è che in realtà è la mancanza di tutto ciò che è considerato sporco. Sembrare pulito, al contrario di essere effettivamente pulito, significa semplicemente che non puoi vedere la sporcizia. Quindi sì, le righe vuote una pletora indubbiamente rendono il tuo codice più pulito in quanto limita la quantità di codice visibile allo stesso tempo, e quindi anche la quantità di impurità del codice è visibile allo stesso tempo. Ma il tuo codice semplicemente pulito non fa nulla per aiutare te o chiunque altro a scrivere o mantenerlo. Al contrario, essere in grado di vedere la sporcizia è un prerequisito per poterlo affrontare.

C'è un argomento abbastanza simile da fare sulla pratica molto più diffusa dell'uso eccessivo di spazi, prendi un pezzo di codice come:

while ( x > y || foo != bar || ! ( a in b ) ) {

Usando uno stile senza spazi predefiniti potrebbero essere stati usati pochi spazi per enfatizzare le tre parti distinte della condizione:

while(x>y || foo!=bar || !(a in b)){

Se hai difficoltà ad abituarti a ridurre gli spazi vuoti, considera la possibilità di configurare il tuo editor per utilizzare un font più grande e / o più linepaces, quindi almeno i tuoi colleghi possono leggere il tuo codice senza problemi e, dato il tempo, potresti essere in grado per modificare gradualmente le impostazioni verso il normale.

L'aggiunta di molti spazi bianchi in una funzione può suddividerla in utili blocchi, ma non fornisce informazioni utili.

Se senti la necessità di aggiungere più di una riga vuota tra le sezioni, dovresti anche aggiungere un commento per spiegare cosa farà il prossimo bit di codice.

Inoltre, come ha sottolineato Thomas Junk, le funzioni troppo lunghe sarebbero meglio suddivise in quelle più piccole e più gestibili.