Alcune regole di buona programmazione

Gran parte del mio lavoro consiste nell’avere a che fare con del codice che verrà eseguito da qualche parte. PHP, JavaScript, un server, un browser, importa relativamente.

Spesso capita di avere a che fare con codice scritto da altri e capirci poco. Ci sta: non possiamo essere nella testa di un’altra persona, e fare reverse engineering a volte prende più tempo del normale.

Succede altre volte, invece, di avere il proprio codice davanti agli occhi, e capirci poco comunque. Codice magari vecchio di solo qualche mese. Personalmente, quando mi ritrovo ad aver a che fare con qualcosa di mio scritto più di un anno addietro, guardo a quel codice come un archeologo guarderebbe un reperto sepolto da centrimentri di polvere, scoperto quasi per caso, trattandolo con la circospezione di chi non vuole rompere nulla.

Di recente, tuttavia, ho notato che questo accade sempre meno, ovvero riesco sempre più a guardare codice mio indiscutibilmente vecchio, senza per questo avere impulsi irrefrenabili che mi porterebbero alternativamente a sbattere la testa contro un muro, o riscrivere tutto quanto solo per capriccio.

Magari sono solo migliorato col tempo. Si impara sbagliando, dicevo settimana scorsa. Magari, però, mi sono messo in condizione di fare qualche favore al futuro Andrea che dovrà avere a che fare con il codice che scrivo oggi, usando qualche accorgimento che, mi sento di poter dire, funziona.

Segue ideale top five, snocciolata senza un ordine particolare:

5. Evitare di scrivere codice criptico

Certo, ogni volta che scriviamo del codice, a prescindere dalla funzione che andrà a svolgere, potremmo scriverlo in meno righe, meno caratteri, astraendo ad libitum. Ma saremo ancora in grado di guardarlo tra sei mesi e capire istantaneamente cosa fa?

Il codice va scritto per le persone, a volte anche per le nostre stesse controparti del futuro, quindi facciamoci il favore di renderlo intelleggibile.

4. Commentare, commentare commentare…

Studi recenti dimostrano che aggiungere un commento in corrispondenza della definizione di una classe, una funzione, o un passaggio di una routine convoluta non porta a sviluppare patologie incurabili. Se lo si fa seguendo uno standard, anche meglio.

3. …ma non commentare troppo

Stiamo scrivendo codice, non un sonetto in endecasillabi, quindi aggiungere un commento per ogni riga che scriviamo risulterà inevitabilmente ridondante. Vale, del resto, sempre il punto numero 5: se il codice necessita di essere spiegato passo-passo, forse non è sufficientemente chiaro di suo.

2. Consentire di poter alterare il funzionamento “dall’esterno”

Se stiamo scrivendo una libreria, probabilmente aggiungeremo dei parametri con cui inizializzarla e sfruttarla in maniera differente a seconda del valore dei parametri stessi.

Lo stesso concetto lo possiamo applicare praticamente ad ogni tipo di codice che scriviamo: rendere modificabile e prevedibile il risultato della sua esecuzione, senza toccare il cuore dello stesso.

WordPress, in tal senso, fornisce già di suo gli strumenti per permettere di intervenire “dall’esterno” utilizzando filtri e azioni.

1. Essere pigri è una buona cosa

La pigrizia generalmente è vista come concetto negativo. In programmazione, tuttavia, essere pigri può diventare velocemente un punto di forza del nostro skillset.

Essere pigri, per me, vuol dire anche ottimizzare il proprio flusso di lavoro. Ad esempio, se qualcosa può essere automatizzato, è bene che lo sia. Dici, “ma risparmio sì e no un paio di secondi!”.

Certo, ma quando andremo a sommare tutte le ottimizzazioni del workflow e valutare tutto il tempo che non avremo passato a fare operazioni noiose e ripetitive, beh forse saremo ancor più convinti che essere pigri, in questo campo, non sia poi così male.