Here’s what NASA has to say about these rules:

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.

Gerard J. Holzmann

The Power of 10 Rules was created in 2006 by Gerard J. Holzmann of the NASA/JPL Laboratory for Reliable Software. The rules are intended to eliminate certain C coding practices which made code difficult to review or to statically analyse.

These rules are a complement to the MISRA C guidelines and have been incorporated into the greater set of JPL coding standards.

The 10 Rules

  1. Avoid complex flow constructs, such as goto and recursion
  2. All loops must have fixed bounds (this prevents runaway code)
  3. Avoid heap memory allocation
  4. Restrict functions to a single printed page
  5. Use a minimum of two runtime assertions per function
  6. Restrict the scope of data to the smallest possible
  7. Check the return value of all nonvoid functions, or cast to void to indicate the return value is useless
  8. Use the preprocessor sparingly
  9. Limit pointer use to a single dereference, and do not use function pointers
  10. Compile with all possible warnings active; all warnings should then be addressed before the release of the software

Those rules were defined for the C language, but some of them might be used also in modern web or mobile projects. The following are my selections.

1. Avoid Complex Flow Constructs, Such as Goto and Recursion

I won’t use recursion if not needed to make the same task that a simple for could handle; recursions are really dangerous in places where you can’t directly access your machine, like if you are on Mars or on the moon or at the bottom of the ocean!

2. All Loops Must-Have Fixed Bounds (This Prevents Runaway Code)

Similar to the first rule, I will make loops with fixed bounds to prevent infinite loops or runaway code.

4. Restrict Functions to a Single Printed Page

Reducing the length of functions to a single page makes it easier to grasp all the functionalities of a specific routine of your program.

If you go over this length, it would suggest that you are adding too many actions in your code.

Another problem might be that you are not splitting the function into smaller functions to prevent code duplication.

6. Restrict the Scope of Data to the Smallest Possible

Never use var if you are using JavaScript — always prefer to use let to prevent variable leaks or overwrites or even ghosting.

The same things should be done with other languages, such as C#. Use the most protected and smallest scope for your variables, such as private or protected.

10. Compile With All Possible Warnings Active; All Warnings Should Then Be Addressed Before Release of the Software

With JavaScript, you won’t able to compile your code, but you can easily use ESLint or similar tools to get warnings from your code.

You should then remove and fix all of them even if you find them not useful in your opinion.

Now we are all ready to launch our code to Mars!

Mars Curiosity rover