10 rules that allow NASA to write millions of lines of code with minimal errors

Margaret Hamilton is standing next to the Apollo on-board computer source code written to her.

The Jet Propulsion Laboratory is a NASA research center responsible for the majority of US unmanned spacecraft. They write a lot of code there, and they have much less right to make mistakes than ordinary programmers.

JPL is written in C, and on their website there is a document called " JPL Institutional Coding Standard ", describing strict coding standards within the organization. They resemble the rules of programming for embedded (embedded) systems and real-time systems, with limited resources. But many of the rules are just the principles of good programming. Limit the complexity, the maximum simplification for subsequent reading code and debugging, no side effects. We in Hexlet constantly talk about this in webinars and, of course, in the courses themselves. We consider it very important to raise these topics as early as possible, so we begin to talk about functions and side effects in the very first year of the course “ Basics of Programming ”, which is designed for beginners. This is a free course, by the way, and it has a practice in the JavaScript language.

Thanks to habrayuzer Boletus for an important amendment and addition:
In 2006, Gerard Holzmann with the team formulated 10 basic rules for JPL in the document " The Power of 10: Rules for Developing Safety-Critical Code ". They formed the basis of the current standard, along with MISRA C and other additions. Wikipedia article .

Here is a translation of this list.

1. It is necessary to strongly limit the branching and conditions. Do not use goto, setjmp or longjmp, do not use direct or indirect recursion.

   
   

2. All cycles must have a limit. The checking program should be able to easily prove that a certain number of iterations cannot be exceeded. If the limit cannot be proved statically, then the rule is considered violated.

   
   

3. Do not use dynamic memory allocation after initialization.

   
   

4. Any function should fit on one standard sheet of paper, one expression per line and one line per definition. This usually means that the function should not be longer than 60 lines.

   
   

5. There must be at most two asserts per function. Asserts are used to test abnormal conditions that cannot occur during a real run. Asserts should not contain side effects, and the format should be Boolean tests. When the assert falls, a special restore action should start, for example, returning the fall condition back to the calling function. If the testing program proves that the assertion never fails or is never satisfied, then the rule is considered violated. (You can not bypass this rule with the help of meaningless “assert (true)”).

   
   

6. Objects with data must be declared at the lowest (possible) level of visibility.

   
   

7. The return value of a non-void function must be checked by the calling function. The validity of the parameters must be checked within each function.

   
   

8. The preprocessor can only be used to include header files and simple macro definitions. Token pasting, variable functions and recursive macro calls are prohibited. The use of conditional compilation directives is undesirable, but sometimes inevitable. This means that only in rare cases it is appropriate to use more than one or two conditions in compilation directives, even in large projects.

   
   

9. The use of pointers should be limited. Valid no more than one level dereference. Dereference operators must not be hidden in macro definitions or inside a typedef. Function pointers are not allowed.

   
   
10. All code should be compiled with all the included warning'ah, on the most meticulous settings of the compiler from the very first day of development. All code should be compiled with such settings without a single warning. All code should be checked every day (at least once a day, but preferably more often), using the best static code analyzer currently available, and should be analyzed without a single warning.