Tuesday, August 17, 2010

Power of 10 for Safety Critical Code

Just reminding programmers of a good set of safety critical programming rules from the rocket scientists at JPL/NASA.  Gerard Holzmann wrote the Power of 10 rules which are a set of good programming practices that should be considered for programs that demand high levels of quality.

The rule that most applies to static analysis is "Rule 10" which is noted below:

"Compile with all warnings enabled, in pedantic mode, and use one or more modern static source code analyzers. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler's most pedantic setting. All code must compile with these setting without warnings. All code must be checked on each build with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings."  (Rule 10 of Power of 10 Rules)

Gerard notes that "there is no excuse for any serious software development effort not to make use of this technology."  Some may view the "rule of zero warnings" as draconian but Gerard notes that if the analysis gets confused enough to report a problem, then the code should be rewritten to be "trivially valid."  Good code doesn't need to be complex.  If the code is clean, it's not only much less error-prone but also much easier to manage and maintain ongoing.  Think also about the next developer who may be inheriting the code.  Static analysis will find bugs but will also help code be more readable and maintainable.


  1. Yep, Holzmann's always worth reading. He got it down to 10 rules, you picked 1. A while back I had picked that same one, and added another, to make a Very Short Coding Standard.

  2. I'm reading those rules and not sure if they are really good - or even possible to follow in some cases. Mind you, I'm very serious about safety - but those rules seem to me doubtful.

    For example, rule 1 proposes to get rid of setjmp and longjmp. It's possible to implement exceptions and coroutines without them - or even write programs without exceptions and coroutines - but it may be more cumbersome, thus violating the purpose of rules. Or rule 3 proposes to not use the dynamic memory management other than in initialization parts. Some tasks may become impossible to solve with this limitation, because the amount of memory couldn't be known in advance.