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

Margaret Hamilton stands next to the Apollo on-board computer source code written by her

The Jet Propulsion Laboratory is a NASA research center responsible for most U.S. unmanned spacecraft. They write a lot of code there, and they have much less right to error than ordinary programmers.

JPL is written in C, and their website has a document called " JPL Institutional Coding Standard " that describes stringent coding standards within the organization. They resemble programming rules for embedded systems and real-time systems with limited resources. But many of the rules are just the principles of good programming. Limitation of complexity, maximum simplification for subsequent code reading and debugging, no side effects. We at Hekslet 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, " Fundamentals of Programming", Which is designed for beginners. This is a free course, by the way, and it has practice in JavaScript.

Thanks to Habrauser Boletus for the important amendment and addition:
In 2006, Gerard Holzmann and 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 the translation of this list.

1. You need to severely limit 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 verification 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 should be no more than two assertions per function. Assers are used to check for abnormal conditions that cannot occur during a real start. Assets should not contain side effects, and should be Boolean tests in format. When the assertion falls, a special recovery action should start, for example, returning the fall condition back to the calling function. If the verification program proves that the assert is never fails or is never satisfied, then the rule is considered violated. (This rule cannot be bypassed with the meaningless “assert (true)”).

   
   

6. Data objects must be declared at the lowest (possible) level of scope.

   
   

7. The return value of a non-void function must be checked by the calling function. Validity of parameters should be checked inside 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. Using conditional compilation directives is undesirable, but sometimes inevitable. This means that only in rare cases is it appropriate to use more than one or two conditions in compilation directives, even in large projects.

   
   

9. The use of pointers should be limited. No more than one dereferencing level is allowed. Dereferencing 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 warning turned on, on the most meticulous compiler settings 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 available today, and should be analyzed without a single warning.