Esiste un numero ottimale di righe di codice per funzione? [chiuso]

18

Le funzioni non vengono utilizzate solo per ridurre al minimo la duplicazione del codice, ma vengono anche utilizzate per suddividere una funzione lunga in una più piccola per aumentare la leggibilità, oltre a rendere il codice auto-commentato. Tuttavia, questo guadagno non è direttamente inversamente proporzionale al numero di LOC per funzione o metodo; altrimenti avremmo tonnellate di funzioni, ognuna delle quali contiene solo una o due righe di codice.

Questo mi porta a chiedermi: esiste un numero ottimale di LOC per funzione? In tal caso, che cos'è e si discosta tra le lingue?

functions

— Gablin
fonte

6

Vedi Code Complete Vol 2 di Mitch McConnell Capitolo 7 Sezione 4 per un buon momento.

— Peter Turner,

2

@Peter - Penso che intendi "Steve McConnell"

— JohnFx,

Sì, divertente lo scrivo mentre guardo il libro ... Wasnt Mitch McConnell Pres. Il capo dello staff di Bush?

— Peter Turner,

3

Il numero varia quasi sicuramente in base alla lingua: sarei sorpreso di vedere una clausola Prolog a 6 righe, pur essendo perfettamente OK con un metodo Delphi a 20 righe. La mia risposta di seguito è per Smalltalk, che utilizza l'ambiente per incoraggiare metodi brevi.

— Frank Shearar,

1

@Peter Turner: Hm ... da S1 a S15 e da I1 a I11. Sembra che stia confondendo le variabili temporanee con i registri. ^^

— gablin,

33

Invece del numero di righe, il criterio che vorrei usare è che ogni funzione dovrebbe fare solo una cosa e lo fa bene.

— grokus
fonte

Sì, se abbiamo un'unità di lavoro non voglio spostarmi tra 50 funzioni per ottenere il jist di ciò che sta accadendo. Se interrompi le tue funzioni in modo appropriato utilizzando questa metrica, dovrebbero avere dimensioni quasi ragionevoli.

— ChaosPandion,

2

@ChaosPandion: ma la tua unità di lavoro può essere probabilmente espressa come una sequenza di passaggi più elementari. Se stai esaminando la funzione, rivedrai la sequenza dei passaggi, non il codice di ogni singolo passaggio.

— Wizard79,

2

@Lorenzo - In tal caso, ogni passaggio diventa l'unità di lavoro. La funzione genitore diventa una panoramica di alto livello delle unità di lavoro.

— ChaosPandion,

1

Sì, questo è davvero vero. Permettetemi di riformulare la domanda allora: esiste un numero ottimale di LOC per funzioni che fa solo una cosa e la fa bene?

— gablin,

@gablin, difficile da dire e anche i LOC dipendono dalla lingua, ma se aderisci a questo principio, di solito finisci in un intervallo ragionevolmente, diciamo 1 ~ 50.

— grokus,

21

Una vecchia regola del pollice è che una funzione dovrebbe essere interamente visibile sullo schermo, senza la necessità di scorrere.

L'idea di base è che, se non riesci a guardare l'intera funzione alla volta, la funzione è troppo complessa e dovresti dividerla in più parti di base.

Mentre questa regola è molto pratica e utile, la regola formale è che dovresti mantenere solo un singolo passo logico in una funzione. Una funzione fa solo un lavoro elementare, se puoi dividere il lavoro in più pezzi elementari, la funzione deve essere divisa.

— Wizard79
fonte

21

Questa metrica diventa progressivamente più inutile all'aumentare della dimensione / risoluzione media del monitor.

— Adam Lear

2

Il nostro prof di programmazione ha appena detto questo esempio l'altra sera :)

— cdnicoll

2

@Anna: beh, il mio monitor è ad alta risoluzione ma anche il numero di barre degli strumenti / tavolozze / pannello è aumentato. E poi, ora posso usare un font con passo di 14 pt! :)

— Wizard79

4

Le dimensioni 24 x 80 di un terminale non tendono a cambiare.

— alternativa il

1

senza senso, il punto della regola è "riesci a vedere tutto senza scorrere". Con un monitor di grandi dimensioni puoi avere di più nella tua funzione senza violare questa regola, non significa che i monitor di grandi dimensioni possono solo visualizzare piccole funzioni (anche se con tutte le barre degli strumenti e le finestre delle proprietà dell'IDE, questo probabilmente vale ancora: - ))

— gbjbaanb,

15

Non c'è nessuno.

Gli schermi stanno diventando più grandi, le dimensioni dei caratteri più piccole. Le regole empiriche non funzionano così bene quando le persone hanno pollici di dimensioni diverse.

Sii conciso. Se la tua funzione fa più cose, probabilmente è una buona idea suddividerla in altre più piccole.

— Josh K
fonte

Il minimo che puoi fare è dirmi perché pensi che la mia risposta non sia utile.

— Josh K,

7

Penso che qualcuno sia stato offeso dal tuo uso del tag h1 .

— ChaosPandion,

@Chaos: questa è la risposta essenziale.

— Josh K,

6

Forse ero un po 'troppo sottile, ma il mio intento era quello di implicare che non vi è alcun motivo valido per votare la tua risposta. Chiunque abbia compiuto l'atto ha avuto qualche motivo personale casuale per farlo. Potrebbero semplicemente pensare che Josh sia un nome orribile.

— ChaosPandion,

6

Smalltalk ha un modo leggermente insolito di ridurre la dimensione dei metodi. Quando scrivi il codice, lo scrivi in un widget chiamato Browser. Un browser ha due parti principali, divise orizzontalmente. Il tuo codice va nella metà inferiore.

Per impostazione predefinita, un browser non è molto grande. Puoi inserire 5 o 6 righe prima di iniziare lo scorrimento. Lo scorrimento, ovviamente, è leggermente irritante.

Quindi in Smalltalk l'ambiente "ti incoraggia" a scrivere metodi brevi, al massimo di circa 6 righe di lunghezza. (Di solito è molto; Smalltalk è un linguaggio piuttosto conciso.)

— Frank Shearar
fonte

2

Il numero ideale di righe di codice in un metodo è variabile. Fondamentalmente, vuoi solo scrivere abbastanza codice per fare ciò che deve essere fatto nel contesto della definizione della funzione. Penso a questo come a una sorta di principio di responsabilità singola , applicato solo a un metodo anziché a una classe.

Laddove un metodo ha molta logica e una serie di passaggi da completare, ha senso suddividere il metodo in più passaggi discreti. Ognuno di questi passaggi verrebbe estratto in nuovi metodi come richiesto.

"altrimenti avremmo tonnellate di funzioni, ognuna delle quali contiene solo una o due righe di codice."

Meno ogni metodo fa, più facilmente è definito e più semplice da capire e gestire. Non c'è niente di sbagliato nell'avere centinaia di metodi se ne hai bisogno. Inoltre, in linea con l' SRP che ho menzionato in precedenza, diventa più facile estrarre nuove classi quando i metodi sono stati suddivisi in pezzi più piccoli e più gestibili.

— S.Robins
fonte

1

La risposta è ovviamente 42 .

Importante da notare: nessuna funzione può mai violare l' SRP , oppure è necessario affrontare l' inchiesta spagnola .

Alcuni suggerimenti su come ridurre la quantità di linee:

Ci sono commenti che segnano le singole sezioni? Tali sezioni dovrebbero essere funzioni.
Esistono catene if-else o istruzioni switch al di fuori di una fabbrica / costruttore? Il tuo progetto potrebbe aver bisogno di modelli di progettazione migliori per aiutarti a dividere le responsabilità.
Le tue funzioni sono facili da testare? Rendi le tue funzioni facili da testare, cadranno a pezzi.
È complesso e non c'è terra in sigth (mostri di 1000 linee)? Effettua il refactoring degli scarti - questo è refactoring e non salvarlo nella speranza di essere istruito sulle responsabilità dei codici.

— Johannes
fonte

1

Nᴏʙᴏᴅʏ si aspetta che lo spagnolo ... ah bugger, sono un po 'in ritardo qui.

— lasciato il

0

Ecco alcuni indizi:

Se hai problemi a scrivere il commento che spiega lo scopo e l'uso della funzione, è troppo lungo.
Se sei tentato di scrivere un commento che spieghi l'attività di una sezione di codice nella funzione, allora la funzione è troppo lunga.
Se stai incollando il codice da un'altra funzione, sono entrambi troppo lunghi (estrai quel codice come una funzione separata).
Se è necessaria una convenzione di codifica per separare i membri dei dati della classe dalle variabili locali, la funzione è troppo lunga e la classe ha troppi membri.
Se è necessario prendere appunti durante la lettura di una funzione, è troppo lungo.

Avere "tonnellate" di funzioni, ciascuna lunga solo una o due righe, non è necessariamente una cosa negativa. Ho scoperto che quelle piccole funzioni sono state riutilizzate molto più di quanto inizialmente mi aspettassi.

— Kevin Cline
fonte