mercoledì 21 gennaio 2009

Nove regole di bellezza per il codice sorgente

Ho sempre amato un aspetto, nella programmazione dei computer, e cioè che le cose possono essere fatte in moltissimi modi diversi, e non c'è sostanzialmente un modo giusto e uno sbagliato di scrivere un programma per computer.

Tuttavia, esiste certamente un modo migliore ed uno peggiore per scrivere software. Ecco alcune norme basate sull'esperienza che vorrei condividere.

(In ciò che segue intendo per "codice" il "codice sorgente" di un programma per computer)

1. Il codice dovrebbe sempre tendere ad essere "bello"

2. Quasi mai la "bellezza" coincide con la "sinteticità", benché certamente un codice ridondante sia un codice brutto.

3. La "bellezza" di un codice è proporzionale alla sua "leggibilità"

4. Il codice "esplicito" è più bello di quello "implicito"

5. Le strutture "piatte" sono più belle delle strutture "innestate"

6. "Sparso" è più bello di "denso"

7. Un codice utile "in generale" (generico) è da preferire ad uno utile "in particolare" (ad hoc). La genericità è bella.

8. Non esiste un problema di programmazione che non sia risolubile attraverso la scomposizione in sotto-problemi. Perciò un codice bello è un codice "composto".

9. L'espressività di un linguaggio di programmazione si misura in quanti modi differenti è possibile implementare lo stesso algoritmo. Un linguaggio espressivo, solitamente è bello.