How To Code Like The Top Programmers At NASA — 10 Critical Rules


The developers at NASA have one of the most challenging jobs in the programming world. They write code and develop mission-critical applications with safety as their primary concerns.

In such situations, it’s important to follow some serious coding guidelines. These rules cover different aspects of software development like how a software should be written, which language features should be used etc.

Even though it’s difficult to establish a consensus over a good coding standard, NASA’s Jet Propulsion Laboratory (JPL) follows a set of guidelines of code named “The Power of Ten–Rules for Developing Safety Critical Code”.

This guide focuses mainly on code written in C programming languages due to JPL’s long association with the language. But, these guidelines could be easily applied on other programming languages as well.

Laid by JPL lead scientist Gerard J. Holzmann, these strict coding rules focus on security.

NASA’s 10 rules for writing mission-critical code:

1. Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.

2. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.

3. Do not use dynamic memory allocation after initialization.

4. 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.

5. The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).

6. Data objects must be declared at the smallest possible level of scope.

7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.

8. The use of the preprocessor 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. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.

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.

About these rules, here’s what NASA has to say:

The rules act like the seatbelt 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.

Did you find this article helpful? Don’t forget to drop your feedback in the comments section below.

Orginally posted on Fossbytes.


  1. I disagree with most of the rules provided. I’ve been developing software for over 17 years and I can tell you that those rules substantially reduce the ability to be creative. “All loops must have a fixed upper-bound.” Really? So that means you can’t ever utilize a dynamic array? Wow, and functions can only be a maximum of 60 lines long? Umm, there are exceptions to these rules which occur more frequently than not.

    These NASA rules are WAY too restrictive for my liking. The intent is good but I suspect there is not a lot of creativity at NASA when it comes to code development.

    • Let me guess your software is not powering a $450 million space shuttle with about 7 souls on board, or a $100 million satellite. If it did you’d be using such rules too. So what’s the worst possible thing that could happen if your software sprouts a bug. It crashes. So what, you restart it. Not so with mission critical systems/software. They need to be bug free.

    • Their goal is to not kill people and to not destroy billions of dollars of hardware – either of which could occur if any single computation results in a minuscule fractional miscalculation. In their environment, any practice which allows for any slight error can’t be tolerated, ever. Your opinion, from 17 years of unrelated ‘creative’ work, has nothing to do with their demanding requirements. I’ve been developing software for 40 years, and I expect I’ve only ever had to deal with the sort of strictness which characterizes every single activity in their daily environment, for a few short moments in all my experience. Does it actually have to even be stated that creative freedom is the opposite of the purpose of guidelines such as this?

    • @Brice If you’ve actually been developing software for over 17 years and the purpose and value of these rules went over your head then you either somehow missed the context where these rules are being used or you have wasted 17 years.

  2. Brice the difference between you’re experience and what NASA programmers are responsible for is vehicles and missions that costs billions of dollars and human lives. Sure, you’re standard business application doesn’t need any of this… Because it isn’t mission critical. Someone doesn’t die when your program crashes because of a memory leak.

  3. Don’t forget these guys lost the $125 million Mars Orbiter because one engineering team used metric units while another used English units for a key spacecraft operation. They were literally burned very recently as the spacecraft incinerated in the martian atmosphere way off course. One of underlying problems beyond the root cause discovered in the AAR, was code readability as team members entered and exited the project.

  4. Pretty much the same 10 “rules” I independently came up with for my software teams. Mostly from structured software and coupling and cohesion principles, and good basic engineering, little of which is/was taught in schools. My teams appreciated these rules because they also learned almost nothing about reliable software design in school. I appreciated that they took these rules with them as they advanced through their carrers. Software today is mostly an integration effort; writing glue logic that bind various libraries, components, and packages in the framework du jour. Not sure I’d have much faith in it for aerospace, medical, financial or IOT applications. Works fine for the web, though.

  5. Good rules. Upper bounds on loops is a good idea. Even if it’s set to something super high. At least it will exit eventually.

    Compiling daily with no warnings. Eek.scary.


Please enter your comment!
Please enter your name here