NASA’s been writing mission-critical software for space exploration for decades, and now the organization is turning those guidelines into a coding standard for the software development industry.
The NASA Jet Propulsion Laboratory’s (JPL) Laboratory for Reliable Software recently published a set of code guidelines, “The Power of Ten—Rules for Developing Safety Critical Code.” The paper’s author, JPL lead scientist Gerard J. Holzmann, explained that the mass of existing coding guidelines is inconsistent and full of arbitrary rules, rarely allowing for now-essential tasks such as tool-based compliance checks. Existing guidelines, he said, inundate coders with vague rules, causing code quality of even the most critical applications to suffer.
“Most serious software development projects use coding guidelines,” Holzmann wrote. “These guidelines are meant to state what the ground rules are for the software to be written: how it should be structured and which language features should and should not be used. Curiously, there is little consensus on what a good coding standard is.”
Holzmann laid out 10 strict rules for developing software with code safety in mind. The rules were specifically written with the C language in mind (a language NASA recommended for safety-critical code due to its long history and extensive tool support), though the rules can be generalized for coding in any programming language.
1: Restrict all code to very simple control flow constructs. Do not use GOTO statements, setjmp or longjmp constructs, or direct or indirect recursion.
2: All loops must have a fixed upper bound. It must be trivially possible for a checking tool to statically prove that a preset upper bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
3: Do not use dynamic memory allocation after initialization.
4: No function should be longer than what can be printed on a single sheet of paper (in a standard reference format with one line per statement and one line per declaration.) Typically, this means no more than about 60 lines of code per function.
5: The assertion density of the code should average a minimum of two assertions per function. Assertions must always be side effect-free and should be defined as Boolean tests.
6: Data objects must be declared at the smallest possible level of scope.