He recommended JavaScript developers use constructs justified by complexity, use code analyzers to reduce defects, monitor codebase metrics, and analyze types with various tools.

2: All loops must have a fixed upper bound. “This makes static analysis more effective and helps to avoid infinite loops,” Radin wrote. “If [the] limit is exceeded, [the] function returns [an] error and this takes [the] system out of failure state. For sure, this is quite valuable for software with 20 years’ uptime!”

3: Do not use dynamic memory allocation after initialization. “Memory leaks often, spoiled JavaScript developers do not have a culture of managing memory, garbage collectors decrease performance when run, and it is hard to tame,” Radin wrote.

Based on the rule, he recommended JavaScript developers manage variables with respect, watch for memory leaks, and switch JavaScript to static memory mode.

4: No function should be longer than what can be printed on a single sheet of paper. “This fits perfectly for JavaScript. Decomposed code is better to understand, verify and maintain,” Radin wrote.

5: The assertion density of the code should average a minimum of two assertions per function. “[The] specialty of assertions is that they execute in runtime…[the] closest practice for JavaScript is a combination of unit tests and runtime checks for program state conformity with generating errors and errors handling,” Radin wrote.

6: Data objects must be declared at the smallest possible level of scope. “This rule [has] simple intentions behind [it]: to keep data in private scope and avoid unauthorized access. Sounds generic, smart and easy to follow,” Radin wrote.

7: Each calling function must check non-void function return values, and the validity of parameters must be checked inside each function. “Authors of [the] guideline assure that this one is the most violated,” Radin wrote. “And this is easy to believe because in its strictest form it means that even built-in functions should be verified. [In] my opinion it makes sense to verify results of third-party libraries being returned to app code, and function-incoming parameters should be verified for existence and type accordance.”

8: Preprocessor use must be limited to the inclusion of header files and simple macro definitions. “Using preprocessors should be limited in any language,” Radin wrote. “They are not needed since [JavaScript has a] standardized, clean and reliable syntax for putting commands into [the] engine.”

9: The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. This is the only rule Radin admitted a JavaScript developer can’t take anything from.

10: All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. “We all know it… Do not hoard warnings, do not postpone fixes, keep code clean and [keep the] perfectionist inside you alive,” Radin wrote.

Radin’s full explanations for how JavaScript developers can follow NASA’s ten safety-critical code rules are available in Pixels Commander’s blog post.

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.