Why is it difficult to reach a consensus on a coding standard?

The work of the National Aeronautics and Space Administration (NASA) developers is one of the most challenging jobs in the programming world. They write code and develop mission-critical applications, and security is their primary focus.

In this case, it is important for them to develop strict coding guidelines and follow them. These rules cover all aspects of software development, such as how the software should be written, which language features should be used, and so on.

Although it is difficult to reach a consensus on a coding standard, NASA's JPL chief scientist Gerard J. Holzmann has developed a set of code guidelines called "Top Ten Rules for Developing Safety Critical Codes", which is followed by all staff.

Since the work of JPL is related to the C language, this guide focuses on code written in the C programming language. But it can also be flexibly applied to other languages.

NASA's top ten coding guidelines:

1. Simplify the control process: Use a control flow that is as lean as possible to construct a program – don't use setjmp or longjmp constructs, goto statements, and direct or indirect recursive calls.

2. Use a fixed number of upper limits for the loop: all loops must have a fixed upper limit. Must be statically validated by a detection tool that does not reach the preset iteration upper limit. If the upper limit cannot be statically verified, then it can be considered to violate this principle.

3. Do not perform dynamic memory allocation after initialization is complete.

4, do not use lengthy functions: If the standard format is one line of a statement, one line of a statement, then the length of the function should be within the scope of a piece of paper, that is, the code line of each function can not exceed 60.

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

6. Declare data objects at the minimum scope level: This principle is also the basic principle of data hiding. All data objects must be declared with the smallest possible range of levels.

7, check the parameters and return value: should check the return value of the non-empty function after each call to the function, and check the validity of the parameter inside each function.

8. Limit the use of preprocessors: The use of preprocessors is limited only by the inclusion of header files and simple macro definitions. Symbol stitching, variable parameter lists (ellipsis), and recursive macro calls are not allowed. All macros must be extended to complete syntax units. Conditional compilation directives are generally not recommended, but it is not always possible to avoid having to have a tool-based inspector mark each time you do this in your code for good reason.

9. Limit the use of pointers: Specifically, no more than one level of dereference pointer reference is allowed. Unfreed pointer references cannot be hidden in macro definitions or type declarations. Function pointers are not allowed.

10. Compile all the code: From the first day of the development work , compile the code with the compiler opening the highest level warning option. Under this setting, the code must be compiled with zero warnings. The code must pass the source code static analysis tool, check it more than once a day, and the zero warning passes.