Lunghezza e larghezza delle linee "raccomandate" [chiusa]

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

Una buona dimensione per un blocco di codice di base è abbastanza breve, sia in larghezza che in altezza, che puoi proiettare il suo interno durante una revisione del codice di gruppo, e avere tutto in forma senza che il carattere sia così piccolo da il retro della sala conferenze non può leggerlo. Questa dimensione è utile anche se ti viene mai chiesto di spiegare un 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 altamente dipendente dal linguaggio che stavi usando (facendo la stessa cosa in assembler contro C # o Java per esempio).

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

Per quanto riguarda il limite di 80 caratteri per linea - questo è un ritorno ai tempi delle schede perforate. Detto questo, quando le linee crescono troppo a lungo, la leggibilità soffre.

Le lunghezze di file e linee sono misure di effetti secondari di complessità e in quanto tali sono altamente variabili. Quello a cui dovresti mirare è il codice senza complessità non necessaria, non un certo numero massimo di righe.

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

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

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

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

I metodi e le funzioni sono i migliori se possono adattarsi a uno schermo.

I file non dovrebbero essere troppo lunghi. I migliori sono file brevi, in cui è facile capire la classe e l'implementazione.
Una volta ho lavorato a un progetto con un file di 10 righe. Era come leggere un libro molto complesso. Devo dire quanti problemi ha causato l'implementazione?

80 caratteri!

Ricordo di aver visto i file del codice sorgente per i programmi di fatturazione di circa 80 pagine e altro quando ho fatto COBOL. Certo, non riesco a vedere che questo è vicino alla pratica comune, ma 80 caratteri sono ugualmente ridicoli.

Da una vista in classe, se provi ad applicare questo suggerimento su una tipica classe Customer che ha circa 80 proprietà e 20 metodi o giù di lì, dovrai suddividere la classe in molte altre e rendere il codice davvero disordinato .

Cerco di mantenere le lezioni e i metodi brevi, ma non preoccuparti tanto della lunghezza della linea. In questi giorni di ampi schermi e lunghi identificatori, penso che ottanta personaggi siano troppo pochi. Ci vuole un po 'di lavoro per rompere le affermazioni in modo che siano facilmente leggibili, e con un limite di ottanta caratteri, accade abbastanza spesso. Penso che 120 o 130 colonne per riga siano più ragionevoli.