The Power of 10: Rules for Developing Safety-Critical Code

Cet article est une ébauche concernant l’informatique théorique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.
Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.

Cet article est orphelin. Moins de trois articles lui sont liés ().

Vous pouvez aider en ajoutant des liens vers [[The Power of 10: Rules for Developing Safety-Critical Code]] dans les articles relatifs au sujet.

Les règles de puissance de 10 ont été créées en 2006 par Gerard Holzmann du laboratoire NASA / JPL pour un logiciel fiable[1]. Les règles visent à éliminer certaines pratiques de programmation en C qui rendent le code difficile à relire ou à analyser statiquement. Ces règles complètent la norme de programmation MISRA C et ont été intégrées au plus grand ensemble de normes de codage JPL[2].

Règles

Les dix règles sont les suivantes[1] :

  1. Éviter les constructions de flux complexes, telles que goto et récursivité .
  2. Toutes les boucles doivent avoir des limites fixes. Cela évite de créer involontairement des boucles infinis.
  3. Éviter d'allouer de la mémoire sur la heap.
  4. Limiter les fonctions à une seule page affichable sur un écran.
  5. Utiliser un minimum de deux assertions par fonction.
  6. Limiter la portée des variables au plus petit possible.
  7. Vérifier la valeur de retour de toutes les fonctions non-void ou transformer en void pour indiquer que la valeur de retour est inutile.
  8. Utiliser le préprocesseur avec parcimonie.
  9. Limiter l'utilisation du pointeur à un seul déréférencement et ne pas utiliser de pointeur de fonction.
  10. Compiler avec tous les avertissements possibles actifs ; tous les avertissements doivent alors être pris en compte avant la publication du logiciel.

Usages

L'étude de la NASA sur le firmware de commande électronique des gaz de Toyota a révélé au moins 243 violations de ces règles[3],[4].

Voir également

Bibliographie

Références

  1. ↑ a et b The Power of 10: Rules for Developing Safety-Critical Code
  2. ↑ JPL C Coding Standard - JPL Laboratory for Reliable Software
  3. ↑ Unintended Acceleration and Other Embedded Software Bugs, March 1st, 2011, by Michael Barr, Embedded Gurus
  4. ↑ NASA Engineering and Safety Center Technical Assessment Report, National Highway Traffic Safety Administration Toyota Unintended Acceleration Investigation, Appendix A