Sento spesso queste due preziose pratiche di programmazione: (1) le righe di codice devono essere di 80 caratteri o meno e (2) usare nomi descrittivi per variabili, metodi, classi, ecc. Capisco il ragionamento per entrambe queste parole di consiglio, tuttavia , sembrano spesso essere un compromesso reciproco. Se mantengo il mio codice al di sotto di 80 caratteri / riga finisco per usare nomi meno descrittivi (specialmente in Python in cui ogni rientro conta come 4 caratteri) ma se uso nomi più descrittivi, finisco con righe di oltre 80 caratteri.

Quindi, la mia domanda è quale di questi due consigli è più importante rispettare se la scelta deve essere fatta? Mi chiedo questo come programmatore indipendente (hobbista), ma soprattutto dal punto di vista di un ingegnere del software che lavora per un'azienda più grande.

Mantieni pochi trattini, i nomi sono descrittivi e non aver paura di spezzare una linea.

Tieni pochi i trattini.

Spesso quando mi trovo in una lotta tra indentazione e denominazione descrittiva, faccio un passo indietro e guardo il mio livello di incidenza. Se stai rientrando oltre 3 o 4 livelli (2 livelli è automatico e inevitabile in molti casi. Leggi: definizione del metodo di classe), potresti voler ristrutturare il tuo codice, estraendo la funzionalità da una funzione o un metodo.

I tuoi nomi descrittivi

Devi sempre mantenere i tuoi nomi descrittivi. I nomi descrittivi creano un codice autocompensante. Puoi provare ad abbreviare i nomi in alcuni casi, ma la leggibilità viene prima di tutto.

Non aver paura di rompere una linea

Merda succede. Se superi gli 80 caratteri e non vedi comunque di recuperare spazio nella linea, interrompilo. La maggior parte delle lingue non si preoccupa delle interruzioni di riga, quindi suddividi la linea in più. Non solo scegliere una posizione casuale. Mantieni le cose raggruppate logicamente e rientra di un altro livello quando interrompi la linea.

Perché non entrambi?

Innanzitutto, "descrittivo" e "verboso" non sono gli stessi. Ad esempio, se stai scrivendo un ciclo abbastanza locale, iè un nome di variabile molto buono per la variabile di ciclo; current_iteration_index, sebbene discutibilmente più descrittivo e decisamente più dettagliato, è molto peggio e non aggiunge alcuna informazione, perché l'uso di icome una variabile di loop è praticamente universalmente accettato e non ha altro significato i.

I nomi di buone variabili sono descrittivi, in quanto un programmatore che ha familiarità con il linguaggio del linguaggio e le convenzioni del codebase può facilmente indovinare quale sia il loro ruolo, ma sono anche abbastanza concisi da mantenere le cose compatte.

Il limite di 80 caratteri, sebbene originariamente una conseguenza delle limitazioni tecniche dei terminali di testo degli anni '70, è ancora valutato da molti oggi, e anche se ci sono ancora ragioni tecniche (lunghezze massime delle linee in alcuni protocolli di rete, in particolare relative alla posta elettronica), le ragioni più convincenti sono quelle psicologiche e sociali. Si scopre che le lunghezze di linea attorno al segno di 66 caratteri rendono l'esperienza di lettura più comoda per la prosa in linguaggio naturale (le dimensioni del carattere in modo interessante non fanno molta differenza, e di conseguenza, né lo schermo né le dimensioni della carta); I limiti di riga di 80 caratteri sono abbastanza vicini a quello, ma poiché la maggior parte di un tipico pezzo di codice è di solito rientrata di almeno uno o due livelli (il che significa tra 4 e 16 caratteri, a seconda delle impostazioni di rientro),

Un altro effetto di attenersi alle linee di 80 caratteri è che è un buon indicatore di quando le cose sono troppo complicate. Le linee così lunghe sono generalmente causate da una delle seguenti:

• Funziona con un lungo elenco di argomenti; questa non è una buona cosa, perché impediscono la leggibilità e possono facilmente causare bug sottili, ad esempio quando le persone scambiano l'ordine degli argomenti in modo che il compilatore non riesca a catturarlo.
• Espressioni complesse, spesso presenti nei condizionali (ad es. if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); anche questo di solito è piuttosto difficile da decifrare e il codice dovrebbe essere riscritto in qualcosa di più strutturato. Molto probabilmente, l'espressione fa troppo e dovrebbe essere fattorizzata in un metodo o una funzione.
• Letterali lunghi utilizzati nelle chiamate di funzione o nelle espressioni, ad es print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Sposta il letterale in una variabile o costante; potrebbe comunque superare la lunghezza della linea, ma se lo fai in modo coerente, il lettore può almeno tranquillamente ignorare la parte invisibile della linea, supponendo che segua solo il resto del letterale. O meglio ancora, sposta i valori letterali fuori dal codice e in un archivio dati esterno (file, database, qualunque cosa).
• Dichiarazioni profondamente annidate, ad esempio sei livelli di ifistruzioni in un metodo di classe (ovvero 32 colonne di rientro per impostazioni tipiche). Ancora una volta, l'annidamento profondo rende il codice complesso e difficile da leggere e dovrebbe essere evitato come la peste - in parole semplici, l'annidamento profondo trabocca nello stack del cervello umano durante la lettura.

Tutti questi sono in definitiva sintomi di cose che preferiresti non avere nella tua base di codice a lungo termine, e applicare limiti di 80 caratteri è un modo piacevole e semplice che aiuta a mantenere bassa la complessità e la leggibilità. (Questo non vuol dire che non puoi scrivere un codice perfettamente illeggibile in 80 colonne: i vari concorsi offuscati-qualcosa-codice sono un chiaro contro-esempio).

La denominazione descrittiva è di gran lunga più importante. Nella maggior parte delle interfacce possiamo scorrere per vedere le linee più lunghe. In nessun caso il sistema può aiutarti a tradurre variabili e funzioni con nomi sbagliati.

80 caratteri per riga non è difficile da incontrare anche i nomi sono lunghi perché ci sono molti modi per suddividere una singola riga di codice lungo in più codici brevi, ad esempio, posso spezzare un'istruzione condizionale in C in più righe per adattarla a meno di 40 personaggi,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

puoi anche dividere una linea di chiamate di funzioni in più linee.

Pertanto, entrambe le regole di denominazione descrittiva e 80 righe di caratteri non hanno contraddizioni, possono coesistere per migliorare la leggibilità.

80 limite è qualcosa che avrebbe dovuto essere aumentato molto tempo fa. Si noti che questo limite viene utilizzato dall'età in cui la lunghezza di ogni identificatore era limitata a 8 caratteri e un solo carattere sullo schermo / stampante. Nessuna possibilità di modificare la dimensione del carattere.

Dio, ora abbiamo diverse tecnologie di stampa e serigrafia. Abbiamo linguaggi di programmazione molto diversi. Non c'è motivo di usare più di 80 caratteri. Aumentalo a 120 caratteri almeno.

Anche allora non dovrebbe essere un limite difficile. Vai un personaggio oltre la linea? Bene, non succede nulla!

Modificare:

Risposte dettagliate sulla storia del limite di 80 caratteri

Personaggi per riga su Wikipedia

Uno studio presso la Wichita State University ha scoperto che la CPL aveva solo piccoli effetti sulla leggibilità, compresi i fattori di velocità e comprensione. Quando sono state richieste le preferenze, tuttavia, il 60% degli intervistati ha indicato una preferenza per le linee più brevi (35 CPL) o più lunghe (95 CPL) utilizzate nello studio. Allo stesso tempo, il 100% degli intervistati ha selezionato una di queste quantità come la meno desiderabile.