NASA's Rules For Writing Mission Critical Code

NASA's Rules for Writing Mission Critical Code

When you're NASA, developing critical applications that lives literally depend on (code that controls aeroplanes and spacecraft, for example), code quality and safety are paramount. That's why they have been looking into coding standards or rules to ensure the reliability of critical software.

Photo by Traveller-Reini.

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 analyser (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 analyse, 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]


Comments

    NASA have the attitude correct with critical code but they have had massive mistakes.
    There are industries that do it better and they have also had to learn from mistakes and errors.
    There is one form of transport industry that works with the rule:
    No single fault or failure (be it software or mechanical) is allowed to cause a safety problem, in other words fail safe.
    Hence, about the safest form of transport in Australia and possibly the world.

      The Motor Industry Software Reliability Association (MISRA) coding standards are a great tool that more SW engineers should be aware of. Sometimes SW engineers are so enamoured with the concept of 'fail safe' that they forget that it contains the word fail. Writing safe enough code which does not fail should be the goal.

Join the discussion!