Lunghezza del file e larghezza della linea "consigliate" [chiuso]

Ero curioso di sapere se qualcuno fosse a conoscenza di una raccomandazione da una fonte attendibile per il numero massimo di righe di codice per un determinato file. Ad esempio, Linter di chiusura di Google raccomanda che ogni riga non superi gli 80 caratteri.

Un file dovrebbe essere abbastanza corto da poter trovare qualsiasi funzione o metodo senza scorrere avanti e indietro più volte per cercarlo o dover ricordare una stringa di ricerca. La metrica che utilizzo è la quantità di tempo che passo alla ricerca di codice all'interno di un file anziché a leggerlo. Se ciò diventa evidente, è tempo di ripartizionare il file o la classe.

Una buona dimensione per un blocco di codice di base è abbastanza corta, sia in larghezza che in altezza, da poter proiettare l'intestino durante una revisione del codice di gruppo, e avere tutto in forma senza che il carattere sia così piccolo che il ragazzo nella parte posteriore di la sala conferenze non riesce a leggerlo. Questa dimensione aiuta anche se sei mai stato chiamato a spiegare del codice quando tutto ciò che hai con te è un dispositivo mobile o un tablet.

Non esiste una cosa del genere, e se ci fosse, sarebbe fortemente dipendente dal linguaggio che stavi usando (facendo la stessa cosa in assemblatore contro C # o Java per esempio).

Per le lingue di livello superiore, puoi vedere questa discussione SO. Per Java / C #, 10-20 righe per metodo è ciò che Bob Martin consiglia al massimo. Non ci sono discussioni sui file, in quanto non è rilevante e dipende da cosa dovrebbe fare la classe.

Per quanto riguarda il limite di 80 caratteri per riga, questo è un ritorno ai giorni delle carte perforate. Detto questo, quando le linee diventano troppo lunghe, la leggibilità ne risente.

Le lunghezze di file e linee sono misure di effetti secondari della complessità e come tali sono altamente variabili. Quello che dovresti mirare è il codice senza inutili complessità, non un certo numero massimo di righe.

I file lunghi tendono a indicare che metodi, subroutine o classi sono eccessivamente complessi (facendo troppe cose, non sufficientemente fattorizzate, ecc.)

Le linee lunghe tendono a indicare che le espressioni sono eccessivamente complesse.

Sono odori che indicano un potenziale problema di codice, non metriche di destinazione ben definite.

La lunghezza della linea dovrebbe essere tale da non dover scorrere lo schermo per vedere l'intera linea. Dipende dalle dimensioni e dalla risoluzione del monitor.

I metodi e le funzioni sono i migliori se possono adattarsi a una schermata.

I file non dovrebbero essere troppo lunghi. I migliori sono file brevi, in cui è facile comprendere la classe e l'implementazione.
Una volta ho lavorato su un progetto che aveva un file di 10 kline. È stato come leggere un libro molto complesso. Devo dire quanti problemi ha causato l'implementazione?

80 caratteri!

Ricordo che quando facevo COBOL vedevo file di codice sorgente per programmi di fatturazione di circa 80 pagine e altro. Certo, non riesco a vedere che questo è vicino alla pratica comune ma 80 caratteri è ugualmente ridicolo.

Dal punto di vista delle dimensioni della classe, se si tenta di applicare questo suggerimento su una tipica classe Customer che ha circa 80 proprietà e circa 20 metodi, sarà necessario suddividere la classe in molte altre e rendere il codice molto caotico.

Cerco di mantenere brevi classi e metodi, ma non mi preoccupo molto della lunghezza della linea. In questi giorni di schermi ampi e identificatori lunghi, penso che ottanta personaggi siano troppo pochi. Ci vuole un po 'di lavoro per infrangere le dichiarazioni in modo che siano facilmente leggibili e, con un limite di ottanta caratteri, accade abbastanza frequentemente. Penso che circa 120 o 130 colonne per riga sia più ragionevole.