Dopo quanta riga di codice deve essere abbattuta una funzione?

Se vuoi cambiare questo codice, scrivi prima i test unitari che ne confermano la funzionalità. Quindi, quando apporti le modifiche, avrai la certezza che non hai rotto niente.

Non esiste una regola ferrea sui numeri di linee, ma una funzione con oltre 40 linee è certamente un suggerimento che è troppo lunga. Una funzione con 2 linee non è troppo piccola. Il codice completo 2 di Steve McConnell si riferisce ad alcuni studi e afferma che 200 righe rappresentano il limite superiore per la leggibilità.

Riguarda la coesione. Una singola funzione dovrebbe eseguire una singola attività e tutte le parti della funzione dovrebbero riguardare direttamente l'esecuzione di tale attività.

Considera la complessità ciclomatica. Un numero elevato di punti decisionali e nidificazione profonda possono indicare un numero eccessivo di codice in una funzione.

Inoltre, i nomi di funzioni e parametri ben selezionati rendono il codice più leggibile perché fungono da una forma di documentazione. Tutto ciò che una funzione dovrebbe essere immediatamente ovvio dalla lettura del suo nome e dei suoi parametri. Se è difficile spiegare cosa fa una funzione in alcune righe di commento, probabilmente hai troppo codice in una funzione.

Ho una semplice linea guida che ho letto da qualche parte forse dieci anni fa. Mi piace quando una definizione di metodo si adatta allo schermo, non mi piace scorrere per leggere.

Credo che la ricerca di metodi più brevi sia buona, ti mette in dubbio se puoi ottenere la stessa funzionalità con meno codice, quindi meno bug. Inoltre, nella mia esperienza quando un metodo è troppo lungo, probabilmente sta facendo troppo.

A mio parere, non è possibile generalizzare quante righe di codice devono contenere un metodo o una classe prima di suddividerla in componenti più piccoli. Invece di contare il numero di righe, dovresti contare quante volte viene riutilizzato un numero di righe. Ad esempio, se hai 3 righe di codice che riutilizzi ancora e ancora all'interno di un metodo o di una classe, allora è una buona idea estrarre questo codice in un metodo.

Un altro aspetto importante è il tuo dominio aziendale. Se inizi a suddividere le tue classi, solo perché pensi che ci siano molte linee di codice, probabilmente dovrai generare nuove classi e metodi, con nuovi nomi, che non si adattano necessariamente al dominio aziendale. Questo tipo di codice è molto difficile da leggere e comprendere per altri sviluppatori (e te stesso dopo alcuni mesi).

Se ritieni che alcuni codici siano inutilmente complessi, dovresti prendere in considerazione la possibilità di riscriverli invece di scomporre il codice. Quando si analizzano e si riscrivono, è possibile che sia una buona idea rompere parte del codice, ma non penso che questo dovrebbe essere l'obiettivo principale. Un codice troppo complesso sarà comunque troppo complesso, anche se è suddiviso.

IMHO dovresti suddividere il tuo codice, quindi fa solo una cosa (senza contare i controlli degli argomenti). In generale, le istruzioni If dovrebbero essere viste come opportunità per estrarre la funzionalità :-) In effetti, il metodo if fa sì che il codice faccia due cose.

Ora, quando farlo è un'altra domanda. Fatelo tranquillamente ogni volta che avete la minima interazione con esso - cioè implementando nuove funzionalità o bugfixing. Se qualcuno ti chiede, lo hai fatto per assicurarti che il tuo nuovo codice funzioni correttamente e che non si possa nemmeno mentire

Preferisco dare le mie funzioni "nomi parlanti", così posso risparmiare sui commenti. Questo porta a molte piccole funzioni, che eseguono operazioni specifiche.

Quindi estraggo una funzione dal codice, se ...

... Io uso il codice in più posti.

... il nome di una funzione diventerebbe piuttosto lungo e implicherebbe molte operazioni di preoccupazioni diverse.

Con questo approccio non finisco mai con una funzione di oltre 50 righe e codice leggibile.

È una regola molto semplice: le funzioni dovrebbero essere brevi. Come in, 5-7 linee.

È quasi sempre utile refactoring di funzioni molto grandi, ma per prima cosa sono necessari i test unitari.

Nota: è molto più facile refactoring di grandi funzioni prima che diventino parte della codebase accettata, e il modo per farlo è la revisione del codice. Cioè quando qualcun altro codifica qualche mostruosità, BLOCCA il commit alla revisione del codice e fagli risolvere il problema.

Non penso che ci sia un limite specifico al numero di linee che una procedura può contenere. Tuttavia, non dovrebbe mai essere nella mente di uno sviluppatore.

Ci sono un paio di cose che si possono applicare per garantire ridimensionamento, gestibilità e leggibilità ai nuovi sviluppatori.

1. Cerca sempre di eseguire tutta l'elaborazione sul lato backend (database) dove possibile quando si tratta di logica. Lascia che le tue stored procedure gestiscano la maggior parte del logica possibile per rilasciare il codice di frontend dell'elaborazione non necessaria (IF, switch istruzioni) in quanto potrebbe avere un costo in termini di prestazioni quando vengono eseguiti più thread prendersi cura di. Questo è ovviamente se la logica utilizza il set di dati da un database.

2. Un metodo dovrebbe sempre avere un'unica responsabilità. Ciò significa che se il tuo metodo
   calcola l'interesse quindi non dovrebbe essere responsabile per l'invio di email all'utente / cliente anche l'interesse quotidiano o un metodo in cui si aggiungono oggetti in un carrello non devono
   gestisci i pagamenti anche per te. Deve avere uno scopo.

3. Un metodo dovrebbe sempre essere aperto per l'estensione e chiuso per la modifica. Modifica il metodo cambia lo scopo e la complessità. Estendendolo mantiene lo scopo e fa è più potente.

4. Piuttosto, avere più classi che separano il lavoro rispetto a una classe che fa tutto il lavoro. Questo rimuove la complessità inutile. Si chiama segregazione interfaccia.

I punti 2,3,4 sono S, O e I dei principal SOLID che assicurano che il codice sia scalabile, gestibile e anche leggibile quando nuovi sviluppatori si uniscono al team.

Per verificare la complessità dei tuoi metodi, esegui le metriche del codice di Visual Studios ( link ). Se Maintainability Index di una classe / metodo è inferiore al 75%, ti avverte di un metodo che diventa complesso da gestire. Ci sono vari altri indicatori che usano la metrica del codice.