Dix guides pour devenir un programmeur de haut niveau pour vous aider à écrire du code de programmation comme la NASA !

Présentation

Citation : Savez-vous comment les meilleurs programmeurs de la NASA écrivent le code critique ? Pour garantir que le code soit plus clair, plus sûr et plus facile à comprendre, le Jet Propulsion Laboratory de la NASA a développé 10 règles de codage.

Le travail de développeur à la NASA est l'un des plus difficiles du monde de la programmation. Leur objectif principal est d'écrire du code et de développer des applications sécurisées et critiques. Pour cette raison, le respect de règles de codage strictes devient crucial. Ces règles couvrent de nombreux aspects du développement logiciel, notamment le style de codage, l'utilisation des fonctionnalités du langage, etc. Bien qu'il soit difficile de s'entendre sur une norme de codage appropriée, le Jet Propulsion Laboratory (JPL) de la NASA suit un ensemble de règles de codage appelées Powers of Ten : Rules for Developing Secure Critical Code.

Ces règles sont principalement destinées aux programmes écrits en C, car le JPL utilise le C depuis longtemps. Cependant, ces règles peuvent également être facilement appliquées à d’autres langages de programmation. Ces règles de codage ont été développées par Gerard J. Holzmann, scientifique en chef du JPL, principalement pour assurer 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 l’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 être plus longue qu'un morceau 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 en moyenne de 2 assertions par fonction. 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 la portée la plus petite possible.
7. La valeur de retour d'une fonction non vide doit être vérifiée à chaque appel de fonction, et la validité de ses paramètres doit être vérifiée au sein de chaque fonction.
8. L'utilisation de préprocesseurs se limite à 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 de 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 ceci à dire :

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!