C'è un motivo valido per imporre una larghezza massima di 80 caratteri in un file di codice, oggi? [chiuso]

Sul serio. Su un monitor da 22 ", copre solo un quarto dello schermo. Ho bisogno di munizioni per rifiutare questa regola.

Non sto dicendo che non ci dovrebbe essere un limite; Sto solo dicendo che 80 caratteri sono molto piccoli.

Penso che la pratica di mantenere il codice su 80 (o 79) colonne sia stata originariamente creata per supportare le persone a modificare il codice su terminali stupidi a 80 colonne o su stampe a 80 colonne. Questi requisiti sono per lo più scomparsi ora, ma ci sono ancora validi motivi per mantenere la regola delle 80 colonne:

• Per evitare il wrapping durante la copia di codice in e-mail, pagine Web e libri.
• Per visualizzare più finestre di origine affiancate o utilizzando un visualizzatore diff side-by-side.
• Per migliorare la leggibilità. Il codice stretto può essere letto rapidamente senza dover scansionare gli occhi da un lato all'altro.

Penso che l'ultimo punto sia il più importante. Sebbene gli schermi siano cresciuti in dimensioni e risoluzione negli ultimi anni, gli occhi no .

L'origine della formattazione del testo a 80 colonne è precedente ai terminali a 80 colonne: la scheda perforata IBM risale al 1928 ! Questo ricorda la storia (apocrifa) secondo cui la sagoma della ferrovia americana era determinata dalla larghezza delle ruote dei carri nella Gran Bretagna romana.

A volte lo trovo un po 'restrittivo, ma ha senso avere un limite standard, quindi è 80 colonne.

Ecco lo stesso argomento trattato da Slashdot .

Ed ecco una dichiarazione Fortran della vecchia scuola:

80 personaggi è un limite ridicolo in questi giorni. Dividi le tue linee di codice dove ha senso, non secondo un limite di caratteri arbitrario.

Dovresti farlo per il bene di tutti coloro che non hanno un monitor widescreen da 22 pollici. Personalmente, lavoro su un monitor 4: 3 da 17 pollici e lo trovo più che sufficientemente ampio. Tuttavia, ho anche 3 di questi monitor, quindi ho ancora molto spazio utilizzabile sullo schermo.

Non solo, ma l'occhio umano ha effettivamente problemi a leggere il testo se le linee sono troppo lunghe. È troppo facile perdersi in quale linea ti trovi. I giornali hanno un diametro di 17 pollici (o qualcosa del genere), ma non li vedi scrivere su tutta la pagina, lo stesso vale per le riviste e altri articoli stampati. In realtà è più facile da leggere se si mantengono le colonne strette.

Quando hai una sequenza di affermazioni che si ripetono con variazioni minori, può essere più facile vedere le somiglianze e le differenze se sono raggruppate in linee in modo che le differenze si allineino verticalmente.

Direi che quanto segue è molto più leggibile di quanto sarebbe stato se lo dividessi su più righe:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Aggiornamento: Nel commento è stato suggerito che questo sarebbe un modo più conciso di fare quanto sopra:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

anche se ora si adatta a 80 colonne, penso che il mio punto sia ancora valido e ho appena preso un cattivo esempio. Dimostra ancora che posizionare più istruzioni su una riga può migliorare la leggibilità.

La stampa di un carattere a spaziatura fissa con dimensioni predefinite è (su carta A4) 80 colonne per 66 linee.

Uso il vantaggio di schermi più grandi per avere più pezzi di codice uno accanto all'altro.

Non otterrai munizioni da me. In effetti, odio vederlo cambiare poiché in situazioni di emergenza vedo ancora rari casi in cui ho bisogno di cambiare il codice da una console di testo.

Le righe superlunghe sono più difficili da leggere. Solo perché puoi visualizzare 300 caratteri sul monitor non significa che dovresti fare le linee così a lungo. 300 caratteri sono anche troppo complessi per un'affermazione a meno che tu non abbia scelta (una chiamata che ha bisogno di un sacco di parametri).

Uso 80 caratteri come regola generale, ma andrò oltre, se applicarlo significherebbe mettere un'interruzione di riga in una posizione indesiderata.

L'unica cosa che impongo di rimanere entro 80 caratteri è il mio commento.

Personalmente ... sto dedicando tutto il mio potere cerebrale (quel poco che c'è) al giusto codice, è un dolore dover tornare indietro e rompere tutto al limite di 80 caratteri quando potrei passare il mio tempo con la prossima funzione . Sì, suppongo che Resharper potrebbe farlo per me, ma poi mi fa un po 'paura che un prodotto di terze parti stia prendendo decisioni sul mio layout del codice e lo cambi ("Per favore, non suddividere il mio codice in due righe HAL. HAL?" ).

Detto questo, lavoro in un team abbastanza piccolo e tutti i nostri monitor sono abbastanza grandi, quindi preoccuparsi di ciò che disturba i miei colleghi programmatori non è una grande preoccupazione.

Sembra però che alcune lingue incoraggino righe di codice più lunghe per motivi di maggiore bang per il dollaro (abbreviazione in caso di affermazioni).

Ho due monitor da 20 "1600x1200 e mi attengo a 80 colonne perché mi consente di visualizzare più finestre dell'editor di testo fianco a fianco. Usando il carattere" 6x13 "(il carattere tradizionale xterm) 80 colonne occupano 480 pixel più la barra di scorrimento e bordi delle finestre. Ciò consente di avere tre finestre di questo tipo su un monitor 1600x1200. Su Windows il font Lucida Console non lo farà (la dimensione minima utilizzabile è 7 pixel di larghezza) ma un monitor 1280x1024 mostrerà due colonne e un monitor 1920x1200 come un HP LP2465 visualizzerà 3. Inoltre lascerà un po 'di spazio sul lato per i vari explorer, proprietà e altre finestre di Visual Studio.

Inoltre, righe di testo molto lunghe sono difficili da leggere. Per il testo l'ottimale è di 66 caratteri. C'è un punto in cui identificatori eccessivamente lunghi iniziano a essere controproducenti perché rendono difficile disporre il codice in modo coerente. Un buon layout e rientro fornisce indicazioni visive sulla struttura del codice e alcuni linguaggi (viene in mente Python) usano esplicitamente il rientro per questo.

Tuttavia, le librerie di classi standard per Java e .Net tendono ad avere una preponderanza di identificatori molto lunghi, quindi non si può necessariamente garantire di essere in grado di farlo. In questo caso, la disposizione del codice con interruzioni di riga aiuta ancora a rendere esplicita la struttura.

Nota che puoi ottenere le versioni di Windows dei caratteri '6x13' qui .

Le persone dicono che lunghe code di codice tendono ad essere complesse. Prendi in considerazione una semplice classe Java:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

È lungo 94 caratteri e il nome della classe è piuttosto breve (secondo gli standard GWT). Sarebbe difficile leggere su 2 righe ed è molto leggibile su una riga. Essendo pragmatico e permettendo così la "compatibilità con le versioni precedenti", direi che 100 caratteri sono della larghezza giusta.

Le altre risposte hanno già riassunto bene le cose, ma vale anche la pena considerare quando potresti voler copiare e incollare un codice in un'e-mail o, in caso contrario, un diff.

Questo è un momento in cui avere una "larghezza massima" è utile.

Non sei l'unica persona che manterrà il tuo codice.

La persona successiva che potrebbe avere uno schermo da 17 "o potrebbe aver bisogno di caratteri di grandi dimensioni per leggere il testo. Il limite deve essere da qualche parte e 80 caratteri è la convenzione a causa delle precedenti limitazioni dello schermo. Riesci a pensare a qualsiasi nuovo standard (120) e perché è una buona idea usare quell'altro "questo è ciò che si adatta al mio monitor con font Xpt?"

Ricorda, ci sono sempre delle eccezioni per ogni regola, quindi hai una riga o un blocco di codice particolare che ha senso essere più di 80 caratteri, quindi essere un ribelle.

Ma prenditi il ​​tempo prima di pensare "questo codice è davvero così male che non può vivere entro 80 caratteri?"

Nello standard di codifica Linux, non solo mantengono il limite di 80 caratteri, ma usano anche 8 rientri di spazio.

Parte del ragionamento è che se mai raggiungi il margine giusto, dovresti considerare di spostare un livello di rientro in una funzione separata.

Ciò renderà il codice più chiaro perché, indipendentemente dalle lunghezze di rientro, è più difficile leggere il codice con molte strutture di controllo nidificate.

Ho ampliato il mio codice a 100 caratteri che si adatta comodamente in meno della metà dello schermo sul mio Macbook. 120 caratteri è probabilmente il limite prima che le linee inizino a diventare troppo lunghe e complesse. Non vuoi allargarti troppo, incoraggia le dichiarazioni composte e le strutture di controllo profondamente annidate.

Il margine giusto è il modo naturale per dirti di eseguire un refactoring con metodo aggiuntivo .

Mi chiedo se questo potrebbe causare più problemi in questo giorno ed età. Ricorda che in C (e possibilmente in altre lingue) ci sono delle regole per quanto tempo può essere il nome di una funzione. Pertanto, spesso vedi nomi molto difficili da capire nel codice C. La cosa buona è che non usano molto spazio. Ma ogni volta che guardo il codice in un linguaggio come C # o Java i nomi dei metodi sono spesso molto lunghi, il che rende quasi impossibile mantenere il codice a una lunghezza di 80 caratteri. Non credo che 80 caratteri siano validi oggi, a meno che tu non debba essere in grado di stampare il codice, ecc.

Come autore delle linee guida di codifica per il mio datore di lavoro ho aumentato la lunghezza della riga da 80 a 132. Perché questo valore? Bene, come altri hanno sottolineato, 80 è la lunghezza di molti vecchi terminali hardware. E anche 132 lo è! È la larghezza della linea quando i terminali sono in modalità ampia . Qualsiasi stampante potrebbe anche effettuare copie cartacee in modalità larga con un carattere condensato.

La ragione per non restare a 80 anni è che preferisco

• preferire nomi più lunghi con un significato per gli identificatori
• non preoccuparti dei typedef per le strutture e le enumerazioni in C (sono MALE, NASCONDONO informazioni utili! Chiedi a Peter van der Linden in "Deep C Secrets" se non ci credi), quindi il codice ha più struct FOO func(struct BAR *aWhatever, ...)del codice dei fanatici di typedef .

e in base a queste regole solo 80 caratteri / linea causano brutti avvolgimenti di linea più spesso di quanto i miei occhi ritengano accettabili (principalmente nei prototipi e nelle definizioni delle funzioni).

Come altri hanno già detto, penso che sia meglio per (1) stampare e (2) visualizzare più file fianco a fianco in verticale.

Mi piace limitare la mia larghezza a circa 100 caratteri per consentire a due editor SxS su un monitor widescreen. Non credo che ci siano più buone ragioni per un limite di esattamente 80 caratteri.

Usa caratteri proporzionali.

Sono serio. Di solito riesco a ottenere l'equivalenza di 100-120 caratteri in una riga senza sacrificare la leggibilità o la stampabilità. In effetti è ancora più facile da leggere con un buon carattere (ad esempio, Verdana) e la colorazione della sintassi. Sembra un po 'strano per alcuni giorni, ma ci si abitua rapidamente.

Cerco di mantenere le cose vicino a 80 caratteri per un semplice motivo: troppo di più significa che il mio codice sta diventando troppo complicato. Nomi di proprietà / metodi troppo dettagliati, nomi di classi, ecc. Causano danni tanto quanto quelli concisi.

Sono principalmente un programmatore Python, quindi questo produce due serie di limitazioni:

1. Non scrivere lunghe righe di codice
2. Non rientrare troppo

Quando inizi a raggiungere due o tre livelli di rientro, la tua logica diventa confusa. Se non riesci a mantenere un singolo blocco nella stessa pagina, il tuo codice sta diventando troppo complicato e difficile da ricordare. Se non riesci a mantenere una sola riga all'interno di 80 caratteri, la tua riga diventa eccessivamente complicata.

In Python è facile scrivere codice relativamente conciso (vedi codegolf) a spese della leggibilità, ma è ancora più semplice scrivere codice dettagliato a spese della leggibilità. I metodi di supporto non sono una cosa negativa, né lo sono le classi di supporto. L'eccessiva astrazione può essere un problema, ma questa è un'altra sfida della programmazione.

In caso di dubbi in un linguaggio come C, scrivi le funzioni di supporto e incorporale se non desideri il sovraccarico di chiamare un'altra funzione e tornare indietro. Nella maggior parte dei casi, il compilatore gestirà le cose in modo intelligente per te.

Ci sono già molte buone risposte a questo, ma vale la pena ricordare che nel tuo IDE potresti avere un elenco di file a sinistra e un elenco di funzioni a destra (o qualsiasi altra configurazione).

Il tuo codice è solo una parte dell'ambiente.

La cosa che non impone 80 caratteri significa infine un ritorno a capo automatico.
IMO, qualsiasi lunghezza scelta per una linea di larghezza massima non è sempre appropriata e il ritorno a capo automatico dovrebbe essere una possibile risposta.
E non è così facile come sembra.

È implementato in jedit _{(fonte: jedit.org )} che offre il ritorno a capo _automatico

Ma è amaramente mancato in un'eclissi da molto tempo ! (dal 2003 in effetti), principalmente perché una parola a capo per l'editor di testo comporta:

• Le informazioni sulla linea a capo sono per il visualizzatore di testo, la navigazione del codice, i righelli verticali.
• Le informazioni sulla riga non imballata sono necessarie per funzionalità come Vai a linea, colonna righello numerazione riga, evidenziazione riga corrente, salvataggio file.

In realtà seguo una regola simile per il mio codice, ma solo a causa della stampa del codice su una pagina A4 - 80 colonne sono circa la larghezza giusta per la dimensione del mio carattere desiderato.

Ma questa è la preferenza personale e probabilmente non quella che cercavi (dal momento che vuoi che le munizioni vadano dall'altra parte).

Cosa non metti in discussione il ragionamento alla base del limite - sul serio, se nessuno può trovare una buona ragione per cui è così, hai una buona ragione per averlo rimosso dai tuoi standard di codifica.

Sto diffondendo fianco a fianco tutto il giorno e non ho un monitor da 22 pollici strano. Non so se lo farò mai. Questo, ovviamente, è di scarso interesse per i programmatori di sola scrittura che si godono la codifica con le frecce e le righe da 300 caratteri.

Sì, perché anche al giorno d'oggi, alcuni di noi stanno codificando sui terminali (ok, principalmente emulatori di terminali), dove il display può visualizzare solo 80 caratteri. Quindi, almeno per la codifica che faccio, apprezzo molto la regola degli 80 caratteri.

Penso ancora che il limite non sia limitato alla parte visiva. Certo, i monitor e le risoluzioni sono abbastanza grandi per mostrare ancora più caratteri in una riga al giorno d'oggi, ma aumenta la leggibilità?

Se il limite è veramente applicato, è anche una buona ragione per ripensare il codice e non mettere tutto in una riga. Lo stesso vale per il rientro: se hai bisogno di molti livelli, il tuo codice deve essere ripensato.

Rompere con 80 caratteri è qualcosa che fai durante la programmazione , non in seguito. Lo stesso vale per i commenti, ovviamente. La maggior parte degli editor può aiutarti a vedere dove si trova il limite di 80 caratteri.

(Questo può essere un po 'OT, ma in Eclipse c'è un'opzione che formatta il codice quando lo salvi (secondo le regole che vuoi). All'inizio è un po' strano, ma dopo un po 'inizi ad accettare che il la formattazione non è più nelle tue mani di quanto sia il codice generato.)

Se avessimo uno di questi , non avremmo questa discussione! ;-)

Ma seriamente i problemi che le persone hanno sollevato nelle loro risposte sono abbastanza legittimi. Tuttavia, il poster originale non stava discutendo contro un limite, semplicemente che 80 colonne sono troppo poche.

Il problema degli e-mail di frammenti di codice ha qualche merito. Ma considerando le cose cattive che la maggior parte dei client di posta elettronica fa al testo preformattato, penso che il ritorno a capo sia solo uno dei tuoi problemi.

Per quanto riguarda la stampa di solito trovo che 100 linee di carattere sarà molto ospitare comodamente su una pagina stampata.

Cerco di mantenere le mie righe sotto 80 colonne. La ragione più forte è che spesso mi trovo a usare grepe lesssfogliare il mio codice quando lavoro dalla riga di comando. Non mi piace davvero come i terminali interrompano le lunghe linee di origine (dopotutto non sono fatti per quel lavoro). Un altro motivo è che trovo meglio se tutto si adatta alla linea e non viene interrotto dall'editor. Ad esempio avere parametri di chiamate a funzioni lunghe ben allineati uno sotto l'altro e cose simili.