When you’re NASA, developing critical applications that lives literally depend on (code that controls airplanes and spacecraft, for example), code quality and safety are paramount. That’s why they’ve been looking into coding standards or rules to ensure the reliability of critical software.
The guidelines were developed by the Jet Propulsion Laboratory (JPL) at the California Institute of Technology, under a contract with NASA, and are currently being used experimentally, with encouraging results, at JPL. While it focuses on code written in C because of the language’s long history and extensive tools support, the guidelines could be adapted for other programming languages and used even if your software programs won’t be used to launch aircraft.
There are 10 rules, to make the set small and clear enough to remember. Some of them are broadly accepted standards for good coding style and practices, such as declaring data objects at the smallest level of scope (rule number 6) and checking code daily with at least one source code analyzer (rule 10). Some might appear strict or confining, such as rule number four:
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.
Rationale:
Each function should be a logical unit in the code that is understandable and verifiable as a unit. It is much harder to understand a logical unit that spans multiple screens on a computer display or multiple pages when printed. Excessively long functions are often a sign of poorly structured code.
As the guidelines paper notes, however, these rules are meant to make it possible to make mission critical code clearer, easier to analyze, and ultimately safer.
Check out the PDF below for the ten rules and their rationales.
The Power of Ten - Rules for Developing Safety Critical Code (PDF) | Pixels Commander via JAXenter
Photo by Traveller-Reini.