Leonardo Casini

Crap code è un termine volgare con cui gli anglofoni chiamano il codice scritto male. In questo articolo l’autore spiega cos’è - secondo lui - il crap code, chiedendo in chiusura anche il parere dei lettori. Quella che segue è la mia idea di crap code, tenendo presente che il concetto di codice buono è soggettivo. Ma fino ad un certo punto…

1. Le infinite catene di if/else annidati sono tra le cose che più irritano il mio senso estetico. Una moltitudine di rami decisionali, uno dentro l’altro, che formano un groviglio inestricabile per la comprensione e sono impossibili da modificare.
2. I metodi, le funzioni o le procedure più lunghi di 20 righe, inclusi i commenti, rendono difficile seguirne il filo logico, spesso sono poco coesi (fanno troppe cose) e di conseguenza scarsamente modificabili.
3. Il codice non commentato è un danno per gli altri, ma anche per sé. Anche se fosse codice ben scritto, una descrizione di ciò che fa dà subito un’idea sommaria che ne aiuta la comprensione più profonda. Lo stesso autore, a distanza di tempo, non può ricordarsi le idee e i ragionamenti che hanno prodotto quel codice: un commento è un messaggio d’aiuto spedito a sé stessi nel futuro.
4. L’utilizzo sbagliato o innaturale delle strutture di controllo, per cercare la creatività a tutti i costi. Usare gli idiomi nel modo consueto facilita agli altri la lettura del proprio codice, così che non debbano spremersi le meningi per capire che quel ciclo while scandisce soltanto gli elementi di una lista dal primo all’ultimo, o che quel try/catch non gestisce un errore, ma il flusso dell’applicazione.
5. L’abuso di flag, che conduce spesso alle catene di if/else di cui sopra e ad espressioni logiche complesse quanto inutili.
6. Le query SQL cablate nel codice e la scansione manuale dei risultati, magari utilizzando indici posizionali (0, 1, 2, …) invece dei nomi degli attributi. Perché non usare un ORM?

L’articolo inoltre enuncia una verità inconfutabile: il crap code è sempre quello degli altri. Voi che ne pensate?