The power of ten
Qualche giorno fa mi sono imbattuto in un video su YouTube how NASA writes space-proof code.
Parla delle 10 regole che la NASA utilizza per sviluppare codice a prova di spazio.
Queste regole sono state implementate nel 2006 dallo sviluppatore Gerard J. Holzmann.
Vengono chiamate The Power of Ten. Sono una serie di regole volte ad eliminare alcune pratiche di codifica C che rendono difficile la revisione o l’analisi statica del codice. Sono inoltre, un complemento alle linee guida del MISRA C e sono state incorporate nello standard di codifica JPL.
Personalmente non ho mail lavorato in C quindi cercherò di analizzare solo quelle regole che secondo me sono applicabili nei linguaggi che utilizzo.
- Evita costrutti di flusso complessi, come goto e ricorsione
- Tutti i loop devono avere limiti fissi. Ciò impedisce il codice in fuga
- Evita l’allocazione della memoria heap
- Limitare le funzioni a una singola pagina stampata
- Utilizza un minimo di due asserzioni di runtime per funzione
- Limita l’ambito dei dati al minimo possibile
- Controlla il valore restituito di tutte le funzioni non void o esegui il cast su void per indicare che il valore restituito è inutile
- Usa il preprocessore con parsimonia
- Limita l’utilizzo del puntatore a un singolo riferimento e non utilizzare i puntatori a funzione
- Compilare con tutti i possibili avvertimenti attivi; tutti gli avvisi dovrebbero quindi essere affrontati prima del rilascio del software
Oggi le analizzeremo insieme per carcare di capire se sono delle possibili best practices da adottare nel nostro lavoro.
Evita costrutti di flusso complessi, come goto e ricorsione
Personalmente ho utilizzato la ricorsione in un solo progetto. E’ difficile che capiti di utilizzarla. Ad ogni modo anche all’università ho imparato che effettivamente non è una buona scelta usare la ricorsione. E’ assolutamente da evitare se esiste un algoritmo iterativo più semplice e più leggibile. Inoltre, è molto difficile da debbagare. Nel caso si dovesse utilizzare è necessario fare attenzione ad avere obbligatoriamente il caso base e controllare che l’algoritmo termini sempre.
Tutti i loop devono avere limiti fissi. Ciò impedisce il codice in fuga
Questo personalmente non lo utilizzo mai. Di solito ciclo sul numero di elementi in un set di dati. Ovviamente utilizzando un ciclo while, cosi come nella ricorsione, è opportuno controllare che la condizione che faccia terminare il ciclo funzioni altrimenti si creerà un ciclo infinito.
Limitare le funzioni a una singola pagina stampata
Questa è una buona prassi perchè rende il codice molto più leggibile. Uncle Bob, sul quale farò presto un articolo, dice che una funziona debba essere di pochissime righe. Questo permette un mantenimento del codice nettamente migliore.
Controlla il valore restituito di tutte le funzioni non void o esegui il cast su void per indicare che il valore restituito è inutile
Non sappiamo chi utilizzerà la funzione che abbiamo creato e anche se abbiamo gestito bene gli errori all’interno della nostra funzione, è buona prassi che chi richiamerà la nostra funzione controlli il dato di ritorno sempre e che sia quello che si aspetti. Questo permette di non far esplodere il nostro progetto.
Ad esempio se il ritorno è di tipo String, in java ad esempio, due dei controlli che eseguo sempre sono:
- diverso da NULL
- diverso da String vuota
Questi 4 punti che ho discusso li includo personalmente come best practices quando sviluppo. Purtroppo queste regole non le insegna nessuno. Personalmente ho imparato delle regole basi che utilizzo regolarmente ma mai un set di regole ben precise. Per questo voglio creare una serie di articoli di questo genere cercando di creare un mio set di regole per sviluppare codice semplice da legere, funzionale e semplice da mantenere.