Sto trovando molti file di linee 2-3k, e non mi sembra proprio che dovrebbero essere così grandi.
Quali sono i criteri validi per chiamare in modo oggettivo un file di codice sorgente "troppo grande" ?, esiste una quantità massima di righe che un file di codice sorgente dovrebbe avere?
Come modello ideale uso i seguenti criteri (con una logica simile a quella suggerita da Martin Beckett, cioè pensare in termini di struttura logica e non in termini di linee di codice):
Regola 1
Una classe per file (in C ++: una classe - > un'intestazione e un file di implementazione).
Regola 2
Sette è considerato il numero di oggetti che il nostro cervello può osservare nello stesso tempo senza confondersi. Sopra 7 abbiamo difficoltà a mantenere una visione d'insieme di ciò che vediamo. Pertanto: ogni classe non dovrebbe avere più di 7-10 metodi. Una classe che ha più di 10 metodi è probabilmente troppo complessa e dovresti provare a dividerla. La divisione è un metodo molto efficace perché ogni volta che dividi una classe riduci la complessità di ogni singola classe almeno di un fattore 2.
Regola 3
Un corpo del metodo che non rientra in uno o due schermi è troppo grande (presumo che una finestra di schermo / editor sia di circa 50 righe). Idealmente, puoi vedere l'intero metodo in una finestra. Se questo non è il caso, devi solo scorrere verso l'alto e verso il basso un po ', senza dimenticare la parte del metodo che viene nascosta. Quindi, se devi scorrere più di una schermata verso l'alto o verso il basso per leggere l'intero corpo del metodo, il tuo metodo è probabilmente troppo grande e puoi facilmente perdere la panoramica.
Anche in questo caso, suddividere i metodi usando metodi di guida privati può ridurre la complessità del metodo molto velocemente (ad ogni scissione la complessità è almeno dimezzata). Se introduci troppi metodi di aiuto privati, puoi considerare di creare una classe separata per raccoglierli (se hai metodi più privati di quelli pubblici, forse una seconda classe si nasconde nella tua classe principale).
Mettere insieme queste stime molto approssimative:
Quindi un file sorgente di oltre 2000 righe è probabilmente troppo grande e inizia a essere troppo disordinato.
Questa è davvero una stima molto approssimativa e non seguo sistematicamente questi criteri (soprattutto perché non c'è sempre abbastanza tempo per fare un corretto refactoring). Inoltre, come suggeriva Martin Beckett, ci sono situazioni in cui una classe è una vasta collezione di metodi e non ha senso dividerli in qualche modo artificiale solo per rendere la classe più piccola.
In ogni caso, nella mia esperienza un file inizia a diventare illeggibile quando uno dei parametri di cui sopra non viene rispettato (ad esempio un corpo di metodo di 300 linee che si estende su sei schermi o un file sorgente con 5000 linee di codice).
No - non in termini di righe di codice. Il driver dovrebbe essere il raggruppamento logico. Certamente non dovrebbero esserci più classi in un unico file di grandi dimensioni, ad esempio
Se tu avessi una classe che legittimamente aveva qualche centinaio di metodi (non impossibile per la modellazione 3D) sarebbe molto meno conveniente dividerlo in file arbitrari. Avevamo bisogno di farlo quando la memoria era scarsa ei processori più lenti - ed era un problema, costantemente alla ricerca della definizione della funzione.
Quando il codice in esso contenuto diventa non mantenibile. cioè: non puoi dirlo semplicemente osservando il codice se il metodo / classe / funzione che stai cercando (e che devi modificare / eseguire il debug) è lì, o no, e se è così, dov'è.
La scelta e le caratteristiche di IDE / Editor influenzeranno comunque la quantificazione effettiva di questo limite massimo. Piegare codice , elenco funzione / metodo e ricerca posticipa nel momento in cui questo scenario di sviluppo presenta.
Ma quando lo fa, è il momento di dividerlo.
Ecco una vista alternativa: stai chiedendo come limitare la dimensione del file. La mia opinione è che ci sono molti fattori che rendono i file di codice di grandi dimensioni molto problematici. A volte il file di codice è enorme, ma il suo contenuto è ben conglobato e il codice estremamente pulito, così che la dimensione non causa problemi significativi. Ho visto molti file che sono molto leggibili nonostante l'alto LOC.
Invece di attingere alla metrica LOC, preferirei pensare a utilizzare i dati della cronologia per capire quanto spesso il codice si rompa in quei file di grandi dimensioni. Di solito la ragione è che gli sviluppatori non hanno il tempo di pazientare per controllare gli altri posti rilevanti nello stesso file e apportare la modifica con la mentalità "quick fix" senza sufficiente comprensione.
Il pericolo maggiore è la presenza del codice copia-incolla. La codifica del copia-incolla naturalmente accelera anche la crescita della LOC. Penso che l'eliminazione della copia-incolla sia ancora più importante che mantenere LOC al di sotto di un numero magico. Oltre al puro copia-incolla, c'è anche un secondo pericolo nei file di grandi dimensioni: funzionalità sovrapposte. Più grande è il file, più è probabile che tu finisca per reimplementare alcuni frammenti di codice che si trovano già in qualche altra sezione dello stesso file.
Quindi, finché la correzione del rapporto di modifica è bassa per i file più grandi, la situazione è tollerabile. Si prega di provare git log per esso e sfogliare quanti dei commit sono legati agli errori. Oppure usa uno strumento che può automaticamente analizzarlo e visualizzarlo, ad es. Softagram .
Leggi altre domande sui tag code-quality code-smell