Ten guides to becoming a top programmer to help you write programming code like NASA!

Introduction

Introduction: Do you know how NASA’s top programmers write mission-critical code? To ensure that code is clearer, safer, and easier to understand, NASA's Jet Propulsion Laboratory has developed 10 coding rules.

The developer job at NASA is one of the most challenging in the programming world. Their primary focus is writing code and developing secure, mission-critical applications. For this reason, adhering to strict coding rules becomes crucial. These rules cover many aspects of software development, including coding style, use of language features, etc. Although it is difficult to agree on an appropriate coding standard, NASA's Jet Propulsion Laboratory (JPL) follows a set of coding rules called Powers of Ten: Rules for Developing Secure Critical Code.

These rules are primarily intended for programs written in C, because JPL has long used C. However, these rules can be easily applied to other programming languages ​​as well. These coding rules were developed by Gerard J. Holzmann, JPL's chief scientist, primarily to ensure security.

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

1. Restrict 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 a piece of paper. Typically this means no more than 60 lines of code per function.
5. The density of assertions in the code averages as low as 2 assertions per function. 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 highest level warning option enabled by the compiler. 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 guides to becoming a top programmer to help you write programming code like NASA!. For more information, please follow other related articles on the PHP Chinese website!