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.
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.
The 10 Rules
- Avoid complex flow constructs, such as
- All loops must have fixed bounds (this prevents runaway code)
- Avoid heap memory allocation
- Restrict functions to a single printed page
- Use a minimum of two runtime assertions per function
- Restrict the scope of data to the smallest possible
- Check the return value of all nonvoid functions, or cast to void to indicate the return value is useless
- Use the preprocessor sparingly
- Limit pointer use to a single dereference, and do not use function pointers
- 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
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
10. Compile With All Possible Warnings Active; All Warnings Should Then Be Addressed Before Release of the Software
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!