Ten programming principles for great NASA programmers

Being a developer at NASA is one of the most challenging jobs in the programming world. They write code and develop secure, mission-critical applications as their primary focus.

In this case, it is important to adhere to some strict coding rules. These rules cover many aspects of software development, such as how software should be coded, which language features should be used, etc.

Although it is difficult to agree on a good coding standard, NASA's Jet Propulsion Laboratory (JPL) adheres to a coding rule called "Powers of Ten: Rules for Developing Secure Critical Code."

Since JPL has long used C language, this rule is mainly for writing in C programming language. But these rules can be easily applied to other programming languages.

Developed by JPL Chief Scientist Gerard J. Holzmann, these strict coding rules are primarily focused on security.

NASA’s 10 Rules for Writing Mission-Critical Code:

1. Limit all code to extremely simple control flow structures - no goto statements, setjmp or longjmp structures, no indirect or direct recursive calls.

2. All loops must have a fixed upper limit. It must be statically confirmed by a detection tool that the loop cannot reach the preset iteration upper limit. If this upper limit cannot be statically proven, then this principle can be considered violated.

3. Do not use dynamic memory allocation after initialization.

4. If you refer to the standard format of one statement per line and one declaration per line, then the length of the function should not be longer than one piece of paper. Typically this means no more than 60 lines of code per function.

5. The density of assertions in the code is as low as 2 assertions per function on average. Assertions are used to detect situations that are unlikely to occur in actual execution. Assertions must have no side effects and should be defined as boolean tests. When an assertion fails, an explicit recovery action should be performed, such as returning an error condition to the caller of the function that failed the assertion. For static tools, any assertion that can be proven by the static tool to never fail or never fire violates this rule (for example, it is impossible to satisfy this rule by adding useless assert(true) statements).

6. Data objects must be declared in the smallest scope.

7. The return value of a non-void function must be checked every time the function is called, and the validity of its parameters must be checked within each function.

8. The use of preprocessors is limited to including header files and simple macro definitions. Symbol splicing, variadic argument lists (ellipses), and recursive macro calls are not allowed. All macros must be expandable into complete syntax units. The use of conditional compilation directives is often obscure, but not always avoidable. This means that even in a large software development more than one or two conditional compilation directives need to have good reasons, beyond the standard practice of avoiding including header files multiple times. Every time you do this in your code it must be flagged by a tool-based checker, and for good reason.

9. The use of pointers should be restricted. In particular there should be no more than one level of pointer dereferencing. Pointer dereferencing operations cannot be implicit in macro definitions or type declarations. Also, function pointers are not allowed.

10. From the first day of development, the code must be compiled with the compiler turning on the highest level warning option. Under this setting, the code must compile with zero warnings. Code must be checked with source code static analysis tools at least once or more per day and pass with zero warnings.
Regarding these rules, NASA has this to say:

These rules are like seat belts in a car. You may feel a little uncomfortable at first, but after a while it will become a habit and you can't imagine not using them.

About the Author:

Adarsh ​​Verma is the co-founder of Fossbytes. He is a respected entrepreneur who has always kept a close eye on open source, technological breakthroughs and completeness. You can contact him by email — [email protected]

The above is the detailed content of Ten programming principles for great NASA programmers. For more information, please follow other related articles on the PHP Chinese website!