Qual è la lunghezza ideale di un metodo per te? [chiuso]

Nella programmazione orientata agli oggetti, ovviamente non esiste una regola esatta sulla lunghezza massima di un metodo, ma ho ancora trovato queste due virgolette in contraddizione tra loro, quindi vorrei sentire cosa ne pensate.

In codice pulito: un manuale di agile software artigianale , Robert Martin afferma:

La prima regola delle funzioni è che dovrebbero essere piccole. La seconda regola delle funzioni è che dovrebbero essere più piccoli di così. Le funzioni non dovrebbero essere lunghe 100 righe. Le funzioni non dovrebbero quasi mai essere lunghe 20 righe.

e fornisce un esempio del codice Java che vede da Kent Beck:

Ogni funzione nel suo programma era lunga solo due, tre o quattro righe. Ognuno era chiaramente ovvio. Ognuno ha raccontato una storia. E ognuno ti ha portato al successivo in un ordine irresistibile. Ecco quanto dovrebbero essere brevi le tue funzioni!

Sembra fantastico, ma d'altra parte, in Code Complete , Steve McConnell dice qualcosa di molto diverso:

Alla routine dovrebbe essere permesso di crescere organicamente fino a 100-200 linee, decenni di prove dicono che routine di tale lunghezza non sono più soggette a errori di routine più brevi.

E dà un riferimento a uno studio che dice che le routine di 65 linee o più lunghe sono più economiche da sviluppare.

Quindi, mentre ci sono opinioni divergenti in merito, esiste una best practice funzionale per te?

Le funzioni dovrebbero normalmente essere brevi, tra 5-15 righe è la mia "regola empirica" ​​personale quando si codifica in Java o C #. Questa è una buona dimensione per diversi motivi:

• Si adatta facilmente allo schermo senza scorrere
• Riguarda le dimensioni concettuali che puoi tenere in testa
• È abbastanza significativo da richiedere una funzione a sé stante (come un pezzo di logica autonomo e significativo)
• Una funzione più piccola di 5 righe è un suggerimento che forse stai rompendo troppo il codice (il che rende più difficile leggere / capire se è necessario navigare tra le funzioni). O quello o stai dimenticando i tuoi casi speciali / gestione degli errori!

Ma non penso che sia utile impostare una regola assoluta, poiché ci saranno sempre valide eccezioni / motivi per discostarsi dalla regola:

• Una funzione di accesso su una riga che esegue un cast di tipo è chiaramente accettabile in alcune situazioni.
• Ci sono alcune funzioni molto brevi ma utili (ad esempio lo scambio come indicato da un utente sconosciuto) che chiaramente richiedono meno di 5 righe. Non è un grosso problema, alcune funzioni a 3 righe non danneggiano la tua base di codice.
• Una funzione a 100 righe che è una singola istruzione switch di grandi dimensioni potrebbe essere accettabile se è estremamente chiaro cosa viene fatto. Questo codice può essere concettualmente molto semplice anche se richiede molte righe per descrivere i diversi casi. A volte si suggerisce che questo dovrebbe essere rifattorizzato in classi separate e implementato usando l'ereditarietà / il polimorfismo, ma IMHO questo sta portando OOP troppo lontano - Preferirei avere solo una grande istruzione switch a 40 vie rispetto a 40 nuove classi da affrontare, inoltre a un'istruzione switch a 40 vie per crearli.
• Una funzione complessa potrebbe avere molte variabili di stato che diventerebbero molto disordinate se passassero tra funzioni diverse come parametri. In questo caso potresti ragionevolmente argomentare che il codice è più semplice e più facile da seguire se mantieni tutto in un'unica grande funzione (anche se, come giustamente sottolinea Mark, questo potrebbe anche essere un candidato per trasformarsi in una classe per incapsulare sia la logica e stato).
• A volte le funzioni più piccole o più grandi hanno vantaggi in termini di prestazioni (forse a causa di motivi inline o JIT come menziona Frank). Questo dipende fortemente dall'implementazione, ma può fare la differenza: assicurati di eseguire il benchmark!

Quindi, fondamentalmente, usa il buon senso , atteniti a piccole dimensioni di funzioni nella maggior parte dei casi, ma non essere dogmatico al riguardo se hai una vera ragione per fare una funzione insolitamente grande.

Mentre sono d'accordo con i commenti degli altri quando hanno detto che non esiste una regola rigida sul giusto numero LOC, scommetto che se guardiamo indietro ai progetti che abbiamo visto in passato e identifichiamo ogni funzione sopra, diciamo 150 righe di codice, io ' Suppongo che arriveremmo a un consenso sul fatto che 9 su 10 di queste funzioni infrangono SRP (e molto probabilmente anche OCP), hanno troppe variabili locali, troppo flusso di controllo e sono generalmente difficili da leggere e mantenere.

Quindi, sebbene LOC possa non essere un indicatore diretto di codice errato, è certamente un indicatore indiretto decente che alcune funzioni potrebbero essere scritte meglio.

Nella mia squadra sono caduto nella posizione di protagonista e per qualsiasi motivo, le persone sembrano ascoltarmi. Quello su cui mi sono generalmente posto d'accordo è dire al team che, sebbene non ci siano limiti assoluti, qualsiasi funzione più di 50 righe di codice dovrebbe almeno sollevare una bandiera rossa durante la revisione del codice, in modo da poterlo rivedere e rivalutare per complessità e violazioni di SRP / OCP. Dopo quella seconda occhiata, potremmo lasciarlo da solo o potremmo cambiarlo, ma almeno fa riflettere le persone su queste cose.

Sono entrato in un progetto che non ha avuto alcuna cura delle linee guida per la programmazione. Quando guardo il codice a volte trovo classi con più di 6000 righe di codice e meno di 10 metodi. Questo è uno scenario horror quando devi correggere i bug.

Una regola generale di quanto dovrebbe essere grande un metodo a volte non è così buona. Mi piace la regola di Robert C. Martin (zio Bob): "I metodi dovrebbero essere piccoli, più piccoli che piccoli". Cerco sempre di usare questa regola. Sto cercando di mantenere i miei metodi semplici e piccoli chiarendo che il mio metodo fa solo una cosa e niente di più.

Non si tratta del numero di righe, si tratta di SRP. Secondo questo principio, il tuo metodo dovrebbe fare solo una cosa.

Se il tuo metodo fa questo E questo E questo O questo => probabilmente sta facendo molto. Prova a guardare questo metodo e ad analizzare: "qui ottengo questi dati, li ordina e ottengo gli elementi di cui ho bisogno" e "qui elaboro questi elementi" e "qui finalmente li combino per ottenere il risultato". Questi "blocchi" dovrebbero essere rifattorizzati con altri metodi.

Se segui semplicemente SRP la maggior parte del tuo metodo sarà piccolo e con chiare intenzioni.

Non è corretto dire "questo metodo è> 20 righe quindi è sbagliato". Può essere un'indicazione che qualcosa non può essere sbagliato in questo metodo, non di più.

Potresti avere un interruttore a 400 linee in un metodo (spesso accade nelle telecomunicazioni), ed è ancora una singola responsabilità ed è perfettamente OK.

Dipende , sul serio, non c'è davvero una risposta solida a questa domanda perché il linguaggio con cui lavori è importante, le cinque o quindici righe menzionate in questa risposta potrebbero funzionare per C # o Java, ma in altre lingue non danno con cui lavorare molto. Allo stesso modo, a seconda del dominio in cui stai lavorando, potresti trovarti a scrivere valori di impostazione del codice in una grande struttura di dati. Con alcune strutture di dati potresti avere decine di elementi che devi impostare, dovresti dividere le cose in funzioni separate solo perché la tua funzione è in esecuzione a lungo?

Come altri hanno notato, la migliore regola empirica è che una funzione dovrebbe essere una singola entità logica che gestisce una singola attività. Se provi ad applicare regole draconiane che affermano che le funzioni non possono essere più lunghe di n righe e rendi quel valore troppo piccolo, il tuo codice diventerà più difficile da leggere mentre gli sviluppatori cercano di usare trucchi fantasiosi per aggirare la regola. Allo stesso modo, se lo si imposta su un valore troppo alto, si tratterà di un problema e può portare a codici errati anche se pigrizia. La tua scommessa migliore è semplicemente condurre revisioni del codice per garantire che le funzioni gestiscano una singola attività e lasciarlo a quello.

Penso che un problema qui sia che la lunghezza di una funzione non dice nulla sulla sua complessità. LOC (Lines of Code) sono uno strumento negativo per misurare qualsiasi cosa.

Un metodo non dovrebbe essere eccessivamente complesso, ma ci sono scenari in cui un metodo lungo può essere facilmente gestito. Si noti che il seguente esempio non dice che non potrebbe essere suddiviso in metodi, ma solo che i metodi non cambieranno la manutenibilità.

ad esempio un gestore per i dati in arrivo può avere una grande istruzione switch e quindi un semplice codice per caso. Ho questo codice: gestire i dati in arrivo da un feed. 70 (!) Gestori con codifica numerica. Ora, si dirà "usa costanti" - sì, tranne che l'API non li fornisce e mi piace stare vicino a "sorgente" qui. Metodi? Certo, purtroppo tutti trattano dati delle stesse 2 enormi strutture. Nessun vantaggio nel dividerli tranne che forse avere più metodi (leggibilità). Il codice non è intrinsecamente complesso - un interruttore, a seconda di un campo. Quindi ogni caso ha un blocco che analizza x elementi di dati e li pubblica. Nessun incubo di manutenzione. C'è una ripetizione "se la condizione che determina se un campo ha dati (pField = pFields [x], se pField-> IsSet () {blabla}) - praticamente per ogni campo.

Sostituiscilo con una routine molto più piccola contenente un ciclo nidificato e molte istruzioni di commutazione reali e un metodo enorme può essere più facile da mantenere rispetto a uno più piccolo.

Quindi, scusa, LOC non è una buona misura per cominciare. Semmai, dovrebbero essere usati punti complessità / decisione.

Aggiungerò solo un'altra citazione.

I programmi devono essere scritti per essere letti dalle persone e solo per inciso per l'esecuzione delle macchine

- Harold Abelson

È molto improbabile che funzioni che raggiungono il 100-200 seguano questa regola

Sono stato in questa folle racchetta, in un modo o nell'altro, dal 1970.

In tutto quel tempo, con due eccezioni che vedrò tra poco, non ho mai visto una "routine" ben progettata (metodo, procedura, funzione, subroutine, qualunque cosa) che DEVE ESSERE più di una pagina stampata ( circa 60 linee) di lunghezza. La stragrande maggioranza di essi era piuttosto corta, nell'ordine di 10-20 linee.

Tuttavia, ho visto MOLTO codice di "flusso di coscienza", scritto da persone che apparentemente non avevano mai sentito parlare di modularizzazione.

Le due eccezioni erano casi molto speciali. Uno è in realtà una classe di casi di eccezione, che raggruppo insieme: grandi automi a stati finiti, implementati come grandi brutte dichiarazioni di commutazione, di solito perché non esiste un modo più pulito per implementarli. Queste cose di solito compaiono in apparecchiature di prova automatizzate, analizzando i registri di dati dal dispositivo in prova.

L'altro era la routine dei siluri fotonici del gioco STARTRK Matuszek-Reynolds-McGehearty-Cohen, scritto in CDC 6600 FORTRAN IV. Doveva analizzare la riga di comando, quindi simulare il volo di ogni siluro, con perturbazioni, controllare l'interazione tra il siluro e ogni tipo di cosa che potesse colpire, e oh, a proposito, simulare la ricorsione per fare connettività a 8 vie su catene di novae da silurare una stella che era accanto ad altre stelle.

Se trovo un metodo lungo, posso scommettere che questo metodo non è adeguatamente testato dall'unità o la maggior parte delle volte non ha affatto un test unitario. Se inizi a fare TDD non costruirai mai metodi a 100 linee con 25 responsabilità diverse e 5 cicli annidati. I test ti obbligano a riformulare costantemente il tuo pasticcio e scrivere il codice pulito di zio Bob.

Non esistono regole assolute sulla lunghezza del metodo, ma sono state utili le seguenti regole:

1. Lo scopo principale della funzione è trovare il valore restituito. Non c'è altra ragione per la sua esistenza. Una volta riempito questo motivo, nessun altro codice deve essere inserito ad esso. Ciò mantiene necessariamente piccole funzioni. La chiamata di altre funzioni dovrebbe essere eseguita solo se è più facile trovare il valore restituito.
2. D'altra parte, le interfacce dovrebbero essere piccole. Ciò significa che hai un gran numero di classi o hai grandi funzioni: una delle due succederà una volta che avrai abbastanza codice per fare qualcosa di significativo. I grandi programmi possono avere entrambi.

Gli autori significano la stessa cosa per "funzione" e "routine"? Tipicamente quando dico "funzione" intendo una subroutine / operazione che restituisce un valore e una "procedura" per uno che non lo fa (e la cui chiamata diventa una singola istruzione). Questa non è una distinzione comune in tutto il mondo reale nel mondo reale, ma l'ho vista nei testi degli utenti.

Ad ogni modo, non esiste una risposta giusta a questo. La preferenza per l'uno o l'altro (se esiste una preferenza) è qualcosa che mi aspetterei di essere molto diverso tra lingue, progetti e organizzazioni; così come è con tutte le convenzioni del codice.

L'unico bit che aggiungerei è che l'intera affermazione "le operazioni lunghe non sono più soggette ad errori delle operazioni brevi" non è strettamente vera. Oltre al fatto che più codice equivale a più potenziale spazio di errore, è palesemente ovvio che la suddivisione del codice in segmenti renderà gli errori più facili da evitare e più facili da individuare. Altrimenti non ci sarebbe motivo di dividere il codice in pezzi, salvo la ripetizione. Ma questo è forse vero solo se detti segmenti sono documentati abbastanza bene da poter determinare i risultati di una chiamata di operazione senza leggere o tracciare il codice effettivo (progettazione per contratto basata su specifiche piuttosto che una dipendenza concreta tra aree di codice).

Inoltre, se si desidera che le operazioni più lunghe funzionino correttamente, è possibile adottare convenzioni di codice più rigorose per supportarle. Lanciare un'istruzione return nel mezzo di un'operazione potrebbe andare bene per un'operazione breve, ma in operazioni più lunghe questo può creare una grande sezione di codice che è condizionale ma non ovviamente condizionata da una lettura rapida (solo per un esempio).

Quindi penso che lo stile che ha meno probabilità di essere un incubo pieno di bug dipenderebbe in gran parte da quali convenzioni aderisci per il resto del tuo codice. :)

IMHO, non dovresti usare la barra di scorrimento per leggere la tua funzione. Non appena è necessario spostare la barra di scorrimento, ci vuole ancora un po 'di tempo per capire come funziona la funzione.

Di conseguenza, dipende dal normale ambiente di programmazione del lavoro di gruppo (risoluzione dello schermo, editor, dimensione del carattere, ecc ...). Negli anni '80, c'erano 25 linee e 80 colonne. Ora, sul mio editor, visualizzo quasi 50 righe. Il numero di colonne che visualizzo non è cambiato da quando ho diviso lo schermo in due per visualizzare due file alla volta.

In breve, dipende dalla configurazione dei tuoi colleghi.

Penso che la risposta di TomTom si sia avvicinata a come la penso.

Sempre più mi trovo ad andare sulla complessità ciclomatica piuttosto che sulle linee.

Di solito non miro a più di una struttura di controllo per metodo, ad eccezione di quanti cicli siano necessari per gestire un array multidimensionale.

A volte mi ritrovo a mettere if di una riga in casi switch perché per qualche ragione questi tendono ad essere casi in cui dividerlo ostacola piuttosto che aiutare.

Si noti che non conto la logica di guardia per questo limite.

In OOP tutto è oggetto e ci sono queste caratteristiche:

1. Polimorfismo
2. Astrazione
3. Eredità

Quando osservi queste regole, i tuoi metodi sono generalmente piccoli ma non esistono regole per regole piccole o molto piccole (ad es. 2-3 righe). Un vantaggio del metodo piccolo (unità piccola, ad es. Metodo o funzione) sono:

1. meglio leggibile
2. mantenere meglio
3. bug risolto meglio
4. cambia meglio