Questo post è liberamente tratto e tradotto da: NASA coding programming rules critical e cioè le regole di programmazione usate alla NASA per scrivere codice cosiddetto “mission-critical”; le regole sono molto restrittive ma costituiscono un ottimo spunto per tutti i programmatori.
Ecco la traduzione
Sapete come programmano alla NASA? Qui spesso serve del codice definito “mission-critical”; ecco perchè, per rendere tale codice più chiaro, sicuro, e semplice da capire, il laboratorio della NASA che si occupa di propulsori dei Jet (JPL), ha stilato 10 regole di programmazione per lo sviluppo del software.
Gli sviluppatori della NASA hanno uno dei lavori più impegnativi nel mondo della programmazione. Loro scrivono codice e sviluppano applicazioni mission-critical aventi la sicurezza come preoccupazione principale.
In tali situazioni, è importante seguire delle linee guida molto serie. Queste regole di programmazione riguardano diversi aspetti dello sviluppo software come il modo in cui un software dovrebbe essere scritto, quale caratteristiche del linguaggio dovrebbero essere usate ecc.
Nonostante sia difficile stabilire consensi unanimi su cosa significhi seguire uno buono standard di programmazione, il laboratorio JPL (Jet Propulsion Laboratory) della NASA segue un insieme di linee guida del codice chiamate: “Le 10 potenti regole di programmazione per la scrittura di codice Mission-Critical”.
Questa guida si focalizza principalmente su codice scritto in linguaggio C da lungo tempo usato alla NASA, ma le regole possono essere facilmente applicate anche agli altri linguaggi di programmazione.
Grazie a Gerard J. Holzmann, sviluppatore e ricercatore del JPL, queste regole di programmazione si focalizzano sulla sicurezza.
Ecco le le prime 5 regole di programmazione per la scrittura di codice mission-critical
- Scrivi tutto il codice con costrutti di controllo del flusso semplici; quindi non usare costrutti di salto (come goto, setjmp o longjmp) nè ricorsione diretta o indiretta
- Tutti i cicli devono avere un limite superiore fisso. Cioè deve essere possibile e semplice, tramite uno strumento di checking, dimostrare statisticamente che, un certo limite superiore prefissato di iterazioni non venga mai superato. Se tale limite non può essere raggiunto statisticamente, la regola è considerata violata.
- Non allocare dinamicamente la memoria dopo l’inizializzazione
- Nessuna funzione dovrebbe essere più lunga di quello che può essere stampato su un singolo foglio di carta con una linea per ogni istruzione e una per ogni dichiarazione. In genere questo vuol dire non più di 60 linee di codice per funzione
- Mantenere la media di due asserzioni per funzione; le asserzioni sono predicati usati per controllare condizioni anomale che non dovrebbero mai verificarsi nelle esecuzioni reali. Le asserzioni inoltre non devono mai avere degli effetti collaterali (side-effects) e, dovrebbero essere definiti sempre come test booleani. Quando un’asserzione fallisce, bisogna prevedere esplicitamente un’azione di recupero: ad esempio restituendo una condizione d’errore alla funzione chiamante.
- Gli oggetti devono essere dichiarati con la più bassa visibilità possibile (preferire ad esempio le variabili locali alle globali).
- Il valore di ritorno delle funzioni non void deve essere controllato da ogni funzione chiamante; la validità di ogni parametro deve essere controllato all’interno di ogni funzione
- L’uso del preprocessore deve essere limitato all’inclusione degli header e alla definizione di semplici macro. Non sono ammessi token pasting (concatenzione di macro che in C si fa tramite l’uso di ##), liste variabili di parametri, chiamate ricorsive di macro. Tutte le macro devono espandersi in unità sintattiche complete. Anche l’uso di direttive per le compilazioni condizionali non è molto consigliato tranne se esiste un valido motivo.
- L’uso dei puntatori deve essere limitato. In particolare è ammesso un solo livello di dereferencing e questo non deve essere nascosto nelle macro o nei typedef. I puntatori a funzione non sono ammessi.
- Il codice deve essere compilato sin dal primo giorno di sviluppo abilitando la segnalazione pedantic dei warning. Tutto il codice deve quindi compilare senza nessuna segnalazione di warning.
Tutto il codice deve essere controllato giornalmente con almeno uno (preferibilmente più di uno) analizzatore di codice (state-of-the-art static source code analyzer); dovrebbe quindi passare l’analisi con zero warning.
…ancora 5 regole di programmazione
Riguardo queste regole la NASA ha affermato:
Le regole sono come la cintura di sicurezza della tua macchina: inizialmente sono scomode, ma dopo un pò usarle diventa naturale ed è inimmaginabile non farlo.
