The Power of 10

Rules for developing safety-critical code

pencil sketch of a face horrible
Oh, it is horrible!

The Power of 10 rules were developed at NASA's Jet Propulsion Laboratory for writing safety-critical code. These guidelines help create more reliable, verifiable, and maintainable software systems.

Originally created for spacecraft software, these principles apply to any system where failure is not an option.

The Ten Rules

Rule 1
Avoid complex flow constructs

Avoid complex flow constructs, such as goto and recursion. These can make code harder to analyze and verify, especially in automated verification tools.

Rule 2
Give all loops fixed bounds

All loops must have fixed upper bounds. It must be trivially possible for a checking tool to prove statically that a preset upper bound on the number of iterations cannot be exceeded.

Rule 3
Avoid heap memory allocation

Avoid heap memory allocation after task initialization. Dynamic memory allocation can lead to unpredictable behavior and memory fragmentation in long-running systems.

Rule 4
Restrict functions to a single page

Restrict functions to no more than 60 lines of text. Each function should be a logical unit that can be easily understood and verified.

Rule 5
Use minimum two runtime assertions per function

Use a minimum of two runtime assertions per function. Assertions must always be side-effect free and should be used to check for anomalous conditions.

Rule 6
Restrict scope of data

Restrict the scope of data to the smallest possible. Global data should be avoided, and when used, access should be carefully controlled and documented.

Rule 7
Check return values

Check the return value of all non-void functions, or cast to void to indicate the return value is useless. Never ignore error conditions.

Rule 8
Limit preprocessor use

Use the preprocessor sparingly. Avoid complex macros and conditional compilation that can make code analysis difficult.

Rule 9
Limit pointer use

Limit pointer use to a single dereference, and do not use function pointers. This reduces complexity and makes static analysis more effective.

Rule 10
Compile with all warnings enabled

Compile with all possible warnings active; all warnings should then be addressed before release of the software.

← Back to homepage