Come evitare il codice spaghetti durante la scrittura di piccole funzioni

Question

La mia comprensione di "Codice spaghetti" è una base di codice che salta da un blocco di codice a un altro senza uno scopo logico e leggibile. Il trasgressore più comune sembra essere la dichiarazione GOTO.

Attualmente sto leggendo/riferendo il capitolo della funzione di Clean Code: un manuale di abilità software agile. L'autore, pur autoreticamente, è estremamente severo sulla dimensione delle funzioni. Capisco l'idea di mantenere le funzioni piccole, tuttavia, suggerisce che dovrebbero essere circa 5 righe. Mentre le Classi diventano certamente più leggibili, ho paura di creare codice spaghetti scrivendo funzioni più piccole. Anche le funzioni più piccole sembrano inavvertitamente creare astrazioni molto più alte.

A che punto il codice diventa codice spaghetti? Quanto è astratto anche lo ? Qualsiasi risposta sarebbe di grande aiuto.

Per inciso, sono un seguace di lunga data di Stack Overflow anche se è la prima volta che faccio una domanda, quindi qualsiasi suggerimento riguardante il mio post è ben accetto.

Grazie mille!

Answer 1

Come già detto nei commenti, non esiste una regola assoluta. Alla fine, dovresti mirare a una buona leggibilità del tuo codice. Ma non è tutto sulla lunghezza dei tuoi metodi. Robert Martin suggerisce di ordinare i metodi in base al grado di astrazione. I metodi Abststract dovrebbero essere al top della classe e più un metodo è, più profondo dovrebbe essere individuato.

Un altro aspetto importand è il nome del metodo. Dovrebbe essere scelto bene per chiarire cosa fa il metodo! Se scegli saggiamente i nomi dei tuoi metodi, i commenti dovrebbero essere difficilmente necessari. Per esempio, si consideri un istruzione if-:

if(isValidAge(value)) { 
    ... 
} 

è molto più leggibile di

if(value > 10 && value < 99) { 
    ... 
} 

perché l'intenzione della dichiarazione diventa molto più chiaro. Per causa potresti aggiungere un commento nel secondo esempio. Ma i commenti diventano spesso superati (c'è un capitolo in più nel libro di Robert Martin su questo). Penso che questo stile di programmazione porti a molti metodi brevi.

È difficile scegliere il giusto livello di astrazione. Secondo la mia esperienza, è più facile iniziare con un basso livello di astrazione. Quindi posso prima concentrarmi sulla soluzione del problema. Quando ho bisogno di più astrazione in un secondo momento, posso ancora refactoring il codice. TDD aiuta molto!

Spero che questo aiuti ...

Answer 2

Sono d'accordo con commenti e risposte qui. Dal punto di vista pratico, i pensieri che Robert Martin scrive nei suoi libri sono sempre ottimi orientamenti e cerco di avvicinarmi il più possibile a queste "regole" e in effetti i metodi a 5 righe non sono per lo più negativi.

Ai miei occhi il modo migliore per evitare il codice spaghetti è scrivere classi (piccole) con un valore alto Cohesion. Lo svantaggio è che diventi un intero gruppo di classi, il che rende talvolta un po 'più difficile per i nuovi dipendenti entrare nel progetto.

Answer 3

Capisco l'idea di mantenere le funzioni piccole, tuttavia, suggerisce che dovrebbero essere circa 5 righe.

Che suona ideale :)

mentre le classi certamente diventano più leggibili, ho paura di creare spaghetti code scrivendo piccole funzioni.

Il codice degli spaghetti è causato dal salto di codice da un posto all'altro con (con diversi livelli di astrazione nella stessa funzione - codice IO di basso livello e logica dell'applicazione di alto livello). Se estrai piccole funzioni, il tuo risultato si sta allontanando dal codice spaghetti, non più vicino).

A che punto il codice diventa codice spaghetti?

Quando il codice obbliga (il programmatore) a fare salti mentali (cambiare contesto) da linea a linea, il codice è codice spaghetti. Questo è vero sia che tu usi GOTO o meno (ma GOTO può peggiorare il problema).