Dalla A alla Z passando per C - Robotica

Capitolo 15
Stile di programmazione
Lo stile di programmazione è un problema che verrà trattato brevemente in questo capitolo.
Per “stile di programmazione” si intendono tutte le scelte stilistiche che sono relative al modo
di presentare il codice sorgente.
Qualunque sia lo stile adottato per la scrittura di un programma, è fondamentale essere
coerenti, facendo rientrare i blocchi sempre allo stesso modo, qualunque esso sia. Lo stile più
diffuso è quello di Kernighan e Ritchie, che prevede di aprire la parentesi graffa a fine riga e
chiudere la parentesi graffa da sola in una riga a se stante. La prefernza stilistica non è molto
importante, quanto invece lo è la coerenza in tutto il codice sorgente.
L’indentazione è una tecnica importante per la stesura di un sorgente chiaro. Per indentazione
si intende il rientro dei blocchi di codice per mezzo di spazi o tabulazioni inserite ad inizio della
riga. Qualunque sia il livello di rientro dei blocchi, 2, 4 o 8 caratteri, il carattere TAB vale 8
spazi1 .
Le funzioni vanno mantenute brevi e comprensibili. Se una funzione diventa troppo complessa
è meglio dividerne il codice in blocchi concettualmente separati, implementandoli sotto forma di
funzioni distinte.
L’utilizzo delle strutture dati migliora la chiarezza e la manutenibilità del programma. Per
gestire le strutture dati, è generalmente meglio definite creatori e distruttori per gli oggetti invece
che usare variabili globali. Ciò significa che è preferibile implementare delle funzioni dedicate
all’inizializzazione dei campi di una struttura, e all’eventuale allocazione/deallocazione della
memoria relativa, invece che dichiarare variabili globali allocate staticamente.
E’ bene controllare e gestire opportunamente sempre tutti gli errori: ogni funzione che viene
chiamata può fallire, e quindi il codice chiamante deve verificare il valore di ritorno e comportarsi
in maniera appropriata, che spesso vuol dire propagare l’errore alla funzione chiamante.
La chiamata alla funzione exit dall’interno di una funzione in caso di errore è da sconsigliare,
ed è meglio lasciate decidere al programma principale come gestire l’errore.
Commentare bene il codice: in linea di massima, evitare costrutti particolarmente furbi, che
possano essere difficili da interpretare da altri programmatori o dallo stesso programmatore a
distanza di tempo. Se tali costrutti vengono utilizzati, è bene spiegare il perché di tale scelta.
Specificare sempre i termini di licenza nel file sorgente. In assenza di permessi specifici vale
la clausola tutti i diritti riservati, ma anche se questa è la vostra intenzione è sempre meglio
specificarlo per chiarire ogni dubbio.
1 Attenzione alla configurazione predefinita dell’ editor che potrebbe essere scorretta.
147