Perché PEP-8 specifica una lunghezza massima di 79 caratteri? [chiuso]


235

Perché in questo millennio Python PEP-8 dovrebbe specificare una lunghezza massima di 79 caratteri?

Praticamente ogni editor di codice sotto il sole può gestire linee più lunghe. Cosa fare con il wrapping dovrebbe essere la scelta del consumatore del contenuto, non la responsabilità del creatore del contenuto.

Ci sono (legittimamente) buone ragioni per aderire a 79 personaggi in questa età?


73
La risposta alla tua domanda è in PEP-8.
cdleary,

29
Le linee più corte aumentano la produttività aumentando il tuo KLOC. : p
Alex

26
Il limite di 79 caratteri è completamente obsoleto. Qualsiasi base di codice modestamente complessa mostra come rende il codice molto più scomodo da leggere. Esempio: github.com/openstack/nova/blob/master/nova/network/manager.py
Jonathan

6
@Jonathan: mi sta benissimo ...
nperson325681

9
Non usate gli strumenti diff side-by-side?
endolith

Risposte:


129

Gran parte del valore di PEP-8 è quello di impedire alle persone di discutere delle regole di formattazione insignificanti e di continuare a scrivere codice valido e formattato in modo coerente. Certo, nessuno pensa davvero che 79 sia ottimale, ma non c'è alcun guadagno evidente nel cambiarlo in 99 o 119 o qualunque sia la lunghezza della linea preferita. Penso che le scelte siano queste: seguire la regola e trovare una causa utile per cui combattere o fornire alcuni dati che dimostrino come la leggibilità e la produttività variano con la lunghezza della linea. Quest'ultimo sarebbe estremamente interessante e penso che abbia buone probabilità di cambiare idea.


28
La maggior parte degli studi di lettura viene eseguita in pollici e non in caratteri per riga. La regola dei 66 caratteri si basa sugli studi fatti per leggere i giornali. Studi recenti hanno dimostrato che durante la lettura di articoli online, la velocità di lettura aumenta fino a circa 120 caratteri per riga (10 pollici con carattere di dimensione 12) senza perdita di comprensione.
Pace

7
In realtà tutti coloro che hanno letto quell'argomento pensano che 79 caratteri siano ottimali. Ecco perché è stato aggiunto a PEP8! Questa risposta è in realtà sbagliata. Questo è quello corretto
erikbwork

6
Pensavo che la domanda fosse: perché 79 è meglio di 80 o 78
n611x007,

157
there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is Questo è così sbagliato in così tanti modi. Avvolgi una riga di 40 caratteri e dimmi quanto è leggibile. Ovviamente meno avvolgimento = maggiore leggibilità fintanto che hai lo spazio sullo schermo, cosa che nel 2015 lo fai. La confezione influisce sulla leggibilità. La leggibilità influisce sulla manutenibilità. La manutenibilità influisce sulla qualità. E la qualità ha un impatto se si arriva a 80 caratteri. Punto.
Jonathan,

6
Discutere della leggibilità con qualsiasi cosa non di codice è inutile poiché quegli studi presuppongono che il testo sia in esecuzione. Il codice appare completamente diverso con una lunghezza della linea diversa (carattere) ogni riga. E anche se scrivi fino alla fine della riga, il rientro modifica la quantità di caratteri per riga.
Corvince,

111

Mantenere il tuo codice leggibile dall'uomo non solo leggibile dalla macchina. Molti dispositivi possono ancora mostrare solo 80 caratteri alla volta. Inoltre semplifica il multi-task per le persone con schermi più grandi, essendo in grado di configurare più finestre affinché siano affiancate.

La leggibilità è anche uno dei motivi per il rientro forzato della riga.


58
Sì, garantito. Ma perché 79? Perché non 100 o 120? Mantenere le cose leggibili funziona in entrambi i modi. Anche la lettura troppo capovolta del codice è difficile da elaborare.
pcorcoran,

17
È vero che molti dispositivi possono mostrare solo 80 caratteri. Quanti di loro non possono eseguire il soft-wrapping?
Jim,

39
Inoltre, si preferisce non disporre del ritorno a capo del codice. Dal punto di vista dell'esperienza dell'utente, è inaccettabile per la maggior parte.
Justin Bozonier,

8
Esistono alcuni sistemi operativi come MVS che non possono gestire linee più lunghe di 72 caratteri. PEP-8 non aiuterà qui. L'impostazione di un limite arbitrario di 79 caratteri non ha senso poiché il carattere dei caratteri per riga dipende dall'editor, dal monitor, dalle preferenze personali dell'utente e così via.
codymanix,

96
79 caratteri fanno inoltre in modo che i programmatori utilizzino variabili più brevi e nomi di funzioni più criptici per adattarsi a tutto. Questo è male per la leggibilità.
Gert Steyn,

46

Sono un programmatore che deve gestire molti codici su base giornaliera. Open source e ciò che è stato sviluppato in casa.

Come programmatore, trovo utile avere molti file sorgente aperti contemporaneamente e spesso organizzo il mio desktop sul mio monitor (widescreen) in modo che due file sorgente siano fianco a fianco. Potrei programmare in entrambi, o semplicemente leggere uno e programmare nell'altro.

Lo trovo insoddisfacente e frustrante quando uno di quei file di origine ha una larghezza> 120 caratteri, perché significa che non posso adattare comodamente una riga di codice su una riga di schermo. Sconvolge la formattazione a capo.

Dico "120" perché questo è il livello al quale sarei infastidito dal fatto che il codice sia più ampio di. Dopo tanti caratteri, dovresti dividere le righe per leggibilità, per non parlare degli standard di codifica.

Scrivo codice pensando a 80 colonne. Questo è solo così che quando perdo oltre quel confine, non è una cosa così brutta.


11
"Scrivo codice con 80 colonne in mente. Questo è così che quando perdo oltre quel limite, non è una cosa così brutta." Stessa cosa per me.
Kobe John

4
10 anni dopo: non dipende solo da come si imposta il wrapping delle linee. L'avvolgimento della linea può essere intelligente o stupido come lo desideri. Se è scomodo da leggere, è solo un errore del tuo editor.
David Mulder,

2
Codifico a 120 caratteri, ma a volte più a lungo quando si adatta alla leggibilità. Formati neri a 120 se lo dici tu. PEP-8 dice anche "va bene aumentare il limite di lunghezza della linea fino a 99 caratteri" ma la gente sembra sopprimere queste informazioni per la maggior parte del tempo. Quasi nessuno usa terminali larghi 80. I messaggi di registro non sono mai larghi 80.
NeilG,

37

Credo che coloro che studiano la tipografia ti direbbero che 66 caratteri per riga dovrebbero essere la larghezza più leggibile per lunghezza. Ciò nonostante, se è necessario eseguire il debug di una macchina in remoto durante una sessione SSH, la maggior parte dei terminali ha un valore predefinito di 80 caratteri, 79 si adatta, provare a lavorare con qualcosa di più ampio diventa un vero problema in questo caso. Saresti anche sorpreso dal numero di sviluppatori che usano vim + screen come ambiente quotidiano.


<flame> Emacs FTW! </flame> +1, però. Penso che il limite 79 venga dai primi giorni di UNIX (e forse MULTICS) che aveva terminali di caratteri 80x25.
Joe D,

10
I miei ambienti ssh + screen + vim non hanno problemi a visualizzare le righe lunghe.
chrishiestand,

54
"66 caratteri per riga dovrebbero essere la larghezza più leggibile per lunghezza" Suppongo che dovremmo scrivere il codice in 2 o 3 colonne, poiché è così che sono disposti i giornali?
Mark E. Haase,

23
@mehaase: il tuo commento sarcastico è abbastanza vicino alla verità: i redattori decenti possono fare pannelli divisi e mostrare cose diverse fianco a fianco (da file uguali o diversi). Per coincidenza, questo di solito è fattibile solo quando il codice ha uno standard di lunghezza di linea ...
nperson325681

2
@mehaase: sembra fantastico, in realtà. Non sto scherzando.
Teekin,

19

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


11
Accetto questo standard; è valido Ma chi stampa più il codice? Inoltre, chi stampa il codice da un ambiente intollerante al ridimensionamento o ad altre opzioni di formattazione? Quando è stata l'ultima volta che qualcuno che conosci è rimasto sconcertato dalla sua incapacità di rendere una riga di 100 caratteri?
pcorcoran,

3
Perché le persone stampano il codice nel 2012? Questo mi ricorda di andare a una conferenza tecnologica e di aver ricevuto una borsa e un raccoglitore stampato pieno di presentazioni. Sono le persone del 21 ° secolo: mandatemi per e-mail le diapositive oppure la borsa e il raccoglitore stanno andando direttamente in una discarica.
Mark E. Haase,

2
quindi perché 80-1 è meglio di 80-0 o 80-2?
611x007,

11
"alle dimensioni predefinite" dici? Dimmi di più su queste dimensioni predefinite universalmente accettate.
Bruno Bronosky,

15
Sì, diamo priorità al modo in cui il codice appare sulla carta stampata sopra ogni altra cosa.
Jonathan,

8

Ecco perché mi piacciono gli 80 caratteri: al lavoro uso Vim e lavoro su due file alla volta su un monitor in esecuzione su, penso, 1680x1040 (non ricordo mai). Se le righe sono più lunghe, ho difficoltà a leggere i file, anche quando uso il ritorno a capo automatico. Inutile dire che odio avere a che fare con il codice di altre persone perché amano le lunghe file.


non usi vim anche per javascript / html?
elad silver,

2
@eladsilver Non riesco a capire se è uno scherzo? MrGreen
Steven Church il

scusa, non molto profondo con vim, ovviamente se lavori nel web lo usi anche per html / js e quei tipi non hanno mai un limite di 80 caratteri poiché gli sviluppatori front-end non conoscono pep8, quindi rendendo il limite di Python 80-char non risolverà il tuo problema se usi più di solo python. quindi quello che ti chiedo è come gestisci gli altri linguaggi di programmazione?
elad silver

Lavoro in Vim con 120 linee di caratteri. Io uso: diffthis con divisione orizzontale. Se riesci ad adattare solo 160 caratteri su 1680 pixel devi avere una dimensione del carattere grande.
NeilG,

4

Poiché lo spazio bianco ha un significato semantico in Python, alcuni metodi di avvolgimento delle parole potrebbero produrre risultati errati o ambigui, quindi è necessario prevedere dei limiti per evitare tali situazioni. Una lunghezza della linea di 80 caratteri è stata standard da quando abbiamo usato i teletipi, quindi 79 caratteri sembrano una scelta abbastanza sicura.


4
Esistono due diversi tipi di a capo automatico. C'è un involucro rigido, in cui le linee sono spezzate con nuove linee e c'è un involucro morbido, in cui sono visualizzate solo con interruzioni, ma rimangono fisicamente una singola linea. Non vedo alcun problema con quest'ultimo.
Jim,

4
La maggior parte degli editor Python non esegue il wrapping di parole morbide perché produce un codice ambiguo difficile da leggere in una lingua in cui spazi bianchi e rientri sono importanti.
Chris Upchurch,

4
Non produce codice ambiguo o di difficile lettura fintanto che il wrapping viene identificato visivamente in qualche modo. Kate fa questo e funziona benissimo. Se un editor non lo gestisce, questo è un motivo per presentare un bug contro l'editor, non un motivo per imporre uno stile di codifica che eviti il ​​bug.
Jim,

5
Anche se è indicato visivamente, rende il codice molto più difficile da leggere, motivo per cui gli editor Python generalmente non lo supportano.
Chris Upchurch,

Lo hai provato per un lungo periodo di tempo? Io ho. Non rende il codice più difficile da leggere nella mia esperienza. Puoi sostenere l'affermazione secondo cui questo è il motivo per cui gli editor Python non includono la funzione? Non ho mai sentito questa affermazione prima.
Jim,

1

Sono d'accordo con Justin. Per elaborare, righe di codice eccessivamente lunghe sono più difficili da leggere dagli umani e alcune persone potrebbero avere larghezze di console che possono contenere solo 80 caratteri per riga.

La raccomandazione di stile è lì per garantire che il codice che scrivi possa essere letto da quante più persone possibile su quante più piattaforme possibile e nel modo più confortevole possibile.


10
Questa è una discussione pigra. Non sempre le 80 linee danneggiano la leggibilità. Una rapida occhiata a qualsiasi base di codice Python modestamente complessa che si avvolge su 80 linee in realtà dimostra il contrario: che il wrapping delle chiamate di funzione a linea singola a più linee rende più difficile seguire WTF.
Jonathan,

0

perché se lo spingi oltre l'80a colonna significa che stai scrivendo una riga di codice molto lunga e complessa che fa troppo (e quindi dovresti fare il refactoring), o che hai fatto troppo rientro (e quindi dovresti fare il refactoring).


90
-1, non credo che si possa dire categoricamente che qualsiasi linea oltre il limite di 80 caratteri richiede un refactor. I metodi di classe sono già rientrati due volte, aggiungono un altro rientro per un "if", ecc. E una semplice comprensione dell'elenco, ed è abbastanza facile oltrepassare il limite di 80 caratteri.

42
Per non parlare del fatto che se si nominano i simboli in modo tale che siano leggibili dall'uomo, ad esempio "users_directed_graph" invece di "usr_dir_gph", anche una semplice espressione consumerà parecchi caratteri per riga.
Mark E. Haase,

8
Ho sempre trovato in Python che se supero gli 80 caratteri è saggio fermarsi e pensare al perché. Di solito è sbagliata la decisione di progettazione errata.
Mike Vella,

3
Questa è stata anche la mia esperienza. Affronta anche nomi di variabili più lunghi, come sottolinea @mehaase, ma penso che questo sia un vantaggio. Le combinazioni disponibili di tre parole consecutive (nel caso di "users_directed_graph") riducono il numero di componenti che si adattano ragionevolmente in un singolo spazio dei nomi. Considero il codice più vecchio che ho scritto in cui molti nomi di variabili lunghe simili nello stesso spazio dei nomi sono più difficili da leggere e generalmente migliori per il refactoring.
TimClifford,

4
In un linguaggio che richiede rientri per ogni cambiamento di ambito, affermare che 80 righe di caratteri equivalgono alla complessità è un argomento eccessivamente semplicistico. A volte 80 caratteri sono proprio ciò che serve per invocare una funzione. Gli IDE / editor moderni per altre lingue sono abbastanza intelligenti da riconoscerlo e possono discernere quando avvolgere invece di porre restrizioni generali su tutto ciò che danneggia la leggibilità in generale.
Jonathan
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.