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

https://stackoverflow.com/questions/110928

02-07-2019
|

Domanda

Scherzi a parte. Su un 22 " monitor, copre solo forse 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.

Soluzione

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. Tali 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 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 non sono .

Altri suggerimenti

L'origine della formattazione del testo a 80 colonne è precedente ai terminali a 80 colonne: la scheda perforata IBM risale a 1928 ! Questo ricorda la (apocrifo) che la ferrovia USA è stata determinata da la larghezza delle ruote delle bighe nella Gran Bretagna romana.

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

Ecco lo stesso argomento trattato da Slashdot .

Ed ecco una dichiarazione Fortran della vecchia scuola:

80 caratteri è 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 chiunque non abbia 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.

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

Quando hai una sequenza di istruzioni 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;

sebbene ora si adatti 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à.

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 super-lunghe 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 a 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 layout del mio 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 per quanto riguarda ciò.

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

Ho due 20 " 1600x1200 monitor e mi attengo a 80 colonne perché mi consente di visualizzare più finestre dell'editor di testo fianco a fianco. Utilizzando il carattere '6x13' (il carattere tradizionale xterm) 80 colonne occupano 480 pixel più la barra di scorrimento e i bordi della finestra. Ciò consente di avere tre finestre di questo tipo su un monitor 1600x1200. Su Windows il font Lucida Console non lo farà del tutto (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. Verrà inoltre visualizzato un un po 'di spazio a 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 (mi 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' Here .

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

È il momento in cui si ha una "larghezza massima" è utile.

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

La prossima persona che potrebbe avere un 17 " schermo o potrebbe essere necessario 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 un nuovo standard (120) e perché è una buona idea usare quell'altro quindi "è quello che si adatta al mio monitor con font Xpt?" & Quot;

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

Ma prima prenditi il ??tempo di pensare " questo codice è davvero così male da non poter 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.

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

Mi chiedo se questo potrebbe causare più problemi al giorno d'oggi. 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 altri hanno già detto, penso sia meglio per (1) la stampa e (2) la visualizzazione di più file affiancati verticalmente.

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.

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 di dirti di eseguire un refactoring con metodo extra .

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 ti ci abitui rapidamente.

Le persone dicono che lunghe righe 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 al riguardo e consentendo così "retrocompatibilità", direi che 100 caratteri sono la larghezza giusta.

Come autore delle linee guida per la codifica del 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à larga . Qualsiasi stampante potrebbe anche eseguire copie cartacee in modalità larga con un carattere condensato.

La ragione per non rimanere a 80 anni è che preferisco

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

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

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 eccessivamente dettagliati, nomi di classi, ecc. Causano più danni di quelli concisi.

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

Non scrivere lunghe righe di codice
Non indentare 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ù facile 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 vuoi il sovraccarico di chiamare un'altra funzione e saltare 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 che alla fine la parola si sposta 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 la parola a capo

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

Le informazioni sulla riga spostata sono per il visualizzatore di testo, la navigazione del codice, i righelli verticali.
Le informazioni sulla linea non imballata sono necessarie per funzionalità come goto line, 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 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 per 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 mentre codifica, non successivamente. 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 potrebbe 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 a accetta che la formattazione non sia più nelle tue mani di quanto sia il codice generato.)

Se avessimo uno dei questi , non lo faremmo avere 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 pre-formattato, penso che il ritorno a capo sia solo uno dei tuoi problemi.

Per quanto riguarda la stampa, di solito trovo che 100 linee di caratteri molto si adattano comodamente a una pagina stampata.

Cerco di mantenere le mie righe sotto 80 colonne. La ragione più forte è che spesso mi trovo a usare grep e less per sfogliare il mio codice quando lavoro alla 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 l'uno sotto l'altro e cose simili.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow