Dix principes de programmation pour les grands programmeurs de la NASA

Développeur à la NASA est l'un des emplois les plus difficiles dans le monde de la programmation. Ils écrivent du code et développent des applications sécurisées et critiques comme objectif principal.

Dans ce cas, il est important de suivre quelques règles de codage strictes. Ces règles couvrent de nombreux aspects du développement logiciel, tels que la manière dont les logiciels doivent être codés, les fonctionnalités du langage à utiliser, etc.

Bien qu'il soit difficile de s'entendre sur une bonne norme de codage, le Jet Propulsion Laboratory (JPL) de la NASA adhère à une règle de codage appelée « Pouvoirs de dix : règles pour le développement de codes critiques sécurisés ».

Étant donné que JPL utilise depuis longtemps le langage C, cette règle concerne principalement l'écriture en langage de programmation C. Mais ces règles peuvent être facilement appliquées à d’autres langages de programmation.

Développées par Gerard J. Holzmann, scientifique en chef au JPL, ces règles de codage strictes se concentrent principalement sur la sécurité.

Les 10 règles de la NASA pour écrire du code critique :

1. Limitez tout le code à des structures de flux de contrôle extrêmement simples - pas d'instructions goto, de structures setjmp ou longjmp, pas d'appels récursifs indirects ou directs.

2. Toutes les boucles doivent avoir une limite supérieure fixe. Il doit être confirmé statiquement par un outil de détection que la boucle ne peut pas atteindre la limite supérieure d'itération prédéfinie. Si cette limite supérieure ne peut pas être prouvée statiquement, alors ce principe peut être considéré comme violé.

3. N'utilisez pas d'allocation dynamique de mémoire après l'initialisation.

4. Si vous vous référez au format standard d'une instruction par ligne et d'une déclaration par ligne, alors la longueur de la fonction ne doit pas dépasser une feuille de papier. Cela signifie généralement pas plus de 60 lignes de code par fonction.

5. La densité des assertions dans le code est aussi faible que 2 assertions par fonction en moyenne. Les assertions sont utilisées pour détecter des situations qui sont peu susceptibles de se produire lors d'une exécution réelle. Les assertions ne doivent avoir aucun effet secondaire et doivent être définies comme des tests booléens. Lorsqu'une assertion échoue, une action de récupération explicite doit être effectuée, telle que renvoyer une condition d'erreur à l'appelant de la fonction qui a échoué à l'assertion. Pour les outils statiques, toute assertion dont l'outil statique peut prouver qu'elle n'échoue jamais ou ne se déclenche jamais viole cette règle (par exemple, il est impossible de satisfaire cette règle en ajoutant des instructions assert(true) inutiles).

6. Les objets de données doivent être déclarés dans le plus petit périmètre.

7. La valeur de retour d'une fonction non vide doit être vérifiée à chaque fois que la fonction est appelée, et la validité de ses paramètres doit être vérifiée au sein de chaque fonction.

8. L'utilisation de préprocesseurs est limitée à l'inclusion de fichiers d'en-tête et de définitions de macros simples. L'épissage de symboles, les listes d'arguments variadiques (ellipses) et les appels de macro récursifs ne sont pas autorisés. Toutes les macros doivent être extensibles en unités de syntaxe complètes. L'utilisation de directives de compilation conditionnelle est souvent obscure, mais pas toujours évitable. Cela signifie que même dans un développement logiciel de grande envergure, plus d'une ou deux directives de compilation conditionnelle doivent avoir de bonnes raisons, au-delà de la pratique standard consistant à éviter d'inclure plusieurs fois les fichiers d'en-tête. Chaque fois que vous faites cela dans votre code, cela doit être signalé par un vérificateur basé sur un outil, et pour cause.

9. L'utilisation des pointeurs doit être restreinte. En particulier, il ne devrait y avoir qu'un seul niveau de déréférencement de pointeur. Les opérations de déréférencement de pointeur ne peuvent pas être implicites dans les définitions de macro ou les déclarations de type. De plus, les pointeurs de fonction ne sont pas autorisés.

10. Dès le premier jour de développement, le code doit être compilé avec le compilateur activant l'option d'avertissement de plus haut niveau. Avec ce paramètre, le code doit être compilé sans aucun avertissement. Le code doit être vérifié avec des outils d'analyse statique du code source au moins une ou plusieurs fois par jour et réussi sans aucun avertissement.
Concernant ces règles, la NASA a déclaré ceci :

Ces règles sont comme les ceintures de sécurité dans une voiture. Vous pourriez vous sentir un peu mal à l'aise au début, mais après un certain temps, cela deviendra une habitude et vous ne pourrez plus imaginer ne pas les utiliser.

À propos de l'auteur :

Adarsh ​​​​Verma est le co-fondateur de Fossbytes. C'est un entrepreneur respecté qui a toujours porté une attention particulière à l'open source, aux avancées technologiques et à l'exhaustivité. Vous pouvez le contacter par e-mail — [email protected]

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!