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.
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.
You need to severely limit branching and conditions. Do not use goto, setjmp or longjmp, do not use direct or indirect recursion.
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.
Do not use dynamic memory allocation after initialization.
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.
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)”).
Data objects must be declared at the lowest (possible) level of scope.
The return value of a non-void function must be checked by the calling function. Validity of parameters should be checked inside each function.
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.
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.
- 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.