"The Power of Ten: Rules for Developing Safety-Critical Code", written at NASA's Jet Propulsion Laboratory (JPL)
NASA has developed rigorous software engineering practices over decades of mission-critical development. These are known as Gerard Holzmann's Ten Rules for Developing Safety-Critical Code.
Holzmann’s Power of Ten Audits
1. Restrict to simple control flow constructs. Goto statements are forbidden along with setjmp/longjmp, or direct/indirect recursion being all off limits.
2. Give all loops a fixed upper-bound.
3. Do not use dynamic memory allocation after initialization.
4. Limit functions to no more than 60 lines of text.
5. Use minimally two assertions per function on average.
6. Declare data objects at the smallest possible level of scope.
7. Check the return value of non-void functions, and check the validity of function parameters.
8. Limit the use of the preprocessor to file inclusion and maintain simple macros.
9. Limit the use of pointers. Use no more than two levels of dereferencing per expression.
10. Compile with all warnings enabled, and use one or more source code analyzers
The overarching philosophy is that these constraints make code easier to understand and work with. Effective software that engineers can think and execute efficiently ensures the safety of both personnel and high-stakes space-flight assets.
Access the full rulebook with detailed explanations on each rule here : https://www.spinroot.com/p10/
Holzmann’s Power of Ten Audits
1. Restrict to simple control flow constructs. Goto statements are forbidden along with setjmp/longjmp, or direct/indirect recursion being all off limits.
2. Give all loops a fixed upper-bound.
3. Do not use dynamic memory allocation after initialization.
4. Limit functions to no more than 60 lines of text.
5. Use minimally two assertions per function on average.
6. Declare data objects at the smallest possible level of scope.
7. Check the return value of non-void functions, and check the validity of function parameters.
8. Limit the use of the preprocessor to file inclusion and maintain simple macros.
9. Limit the use of pointers. Use no more than two levels of dereferencing per expression.
10. Compile with all warnings enabled, and use one or more source code analyzers
The overarching philosophy is that these constraints make code easier to understand and work with. Effective software that engineers can think and execute efficiently ensures the safety of both personnel and high-stakes space-flight assets.
Access the full rulebook with detailed explanations on each rule here : https://www.spinroot.com/p10/
NASAs Coding Requirements