7: Each calling function must check non-void function return values, and the validity of parameters must be checked inside each function.

8: Preprocessor use must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed.

9: The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.

10: 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 any warnings. All code must be checked daily 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.

Holzmann included detailed rationales for each of these rules in the paper, but the general gist is that together, the rules guarantee a clear and transparent control flow structure to make it easier to build, test and analyze code along broadly accepted but all-around disjointed standards. JPL has developed automated software for deep space missions such as the Mars Curiosity rover and the Voyager probe, and the laboratory is already using the rules on an experimental basis to write mission-critical software.

Holzmann believed that complying with NASA’s rules, strict as they might be, can lessen the burden on developers and lead to better code clarity, analyzability and safety.

“If the rules seem Draconian at first, bear in mind that they are meant to make it possible to check code where very literally your life may depend on its correctness: code that is used to control the airplane that you fly on, the nuclear power plant a few miles from where you live, or the spacecraft that carries astronauts into orbit,” he wrote.

“The rules act like the seat belt in your car: Initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature, and not using them becomes unimaginable.”

Applying NASA’s coding standards to JavaScript
NASA JPL’s rules for developing safety-critical code are broad enough to generalize to writing code in any programming language, but one developer has already connected the dots to the most popular Web development language out there: JavaScript.

Dutch front-end developer Denis Radin, a.k.a. Pixels Commander, published a blog post breaking down how each of NASA’s 10 rules relates to JavaScript. Check out an abridged rundown of how JavaScript developers can adhere to each rule, and where the benefit lies in doing so.

1: Restrict all code to very simple control flow constructs. “Why [do] NASA guidelines prescribe to avoid simple technique we were studying as early as in school? The reason for that is static code analyzers NASA use to reduce the chance for error,” Radin wrote.

About Rob Marvin

Rob Marvin has covered the software development and technology industry as Online & Social Media Editor at SD Times since July 2013. He is a 2013 graduate of the S.I. Newhouse School of Public Communications at Syracuse University with dual degrees in Magazine Journalism and Psychology. Rob enjoys writing about everything from features, entertainment, news and culture to his current work covering the software development industry. Reach him on Twitter at @rjmarvin1.