You won’t be the first and you will not be the last, tech and space have always been closely linked to one and other. Whether you’re a software developer working on an ecommerce platform or a data engineer putting an ETL pipeline together, we all have a fascination with the science that goes into voyages beyond our orbit.  

Like any form of technology, software has now become a key component in any space craft that journeys through the stars, but have you ever thought about complications that can arise from using software in space. Gerard Holzman has, Gerard is a Computer Scientist and Developer for NASA at their jet propulsion laboratory for reliable software (What a place to work hey?), and below are Gerard/NASA’s Power of Ten coding commandments that any of their developers must abide by.   

*Disclaimer: This is a very development heavy article, feel free to google the jargon if it makes no sense* 

Simple Control Flow Constructs 

This means NASA do not use “goto”, “setjump”, or “longjump” statements, a side effect of this rule means they do not use recursion either, recursive code is a function that calls into itself.   

All Loops Must Have Fixed Upper Bounds 

When writing basic loops, its simple for us to have the loop base its endpoint on the content within the loop and not “hard code” the limiter. To prevent run away code, infinite loops, NASA will always put a fixed limit for max iterations on their loops. 

Do Not Use the Heap

NASA requires that their developers use stack memory and stack memory only. Garbage collectors and the Heap have been known to be a source for memory bugs.  

Functions Should Be No Longer Than 60 Lines

As far as NASA is concerned, a function within your code base should do one thing, and one thing only.  To ensure this and to make sure the code readable, NASA requires a function is no longer than 60 lines or a piece of printer paper. This enables quick and easily readable checks in emergencies. This function size also allows the function to be testable as a single unit.  

Data Hiding

Data hiding is the practice of declaring variables as they’re used at the lowest scope possible. As with the previous rules this falls in line with NASA’s wants and wishes to write safe and easily testable code. Data Hiding reduces the amount of code that can access a variable but also reduced the number of places that can go wrong when debugging.  

Check Return Values 

Although you’d expect this in most software teams, the checking all non-void return values is a must for NASA, not just good practice, but this also helps those doing code reviews keep track of whether the developer is paying attention. If a non-void has been set to void, it’s time to have a word.  

Limit the Preprocessor

NASA describes the C preprocessor as a powerful obfuscation tool that can destroy code clarity and befuddle many text-based code analysers.  

Restrict Pointers Used 

NASA requires that pointers should not be referenced more than one layer at a time. NASA sees pointers as a very powerful tool, but a tool that can be used incorrectly with far too much ease. Limiting pointers to one reference at a time allows you to properly structure your pointers.  

Be Pedantic 

Compile with all warnings enabled and compile in pedantic mode, then test all you can!