from NASA/JPL(Jet Propulsion Laboratory)

The result is that most existing guidelines contain well over a hundred rules, sometimes with questionable justification. Some rules especially those that try to stipulate the use of white-space in programs, may have been introduced by personal preference; others are meants to prevent very specific and unlikely types of error from eariler coding efforts within the same organization.

효율적인 가이드라인이 되려면, rule의 개수는 적어야 하고, 쉽게 이해되고, 기억될 수 있을 만큼 명확해야 한다.
규칙은 기계적으로 검사할 수 있을 만큼 구체적이어야 한다.

Rule 1 모든 코드는 매우 간단한 control flow를 가져야 한다.

goto, setjmp, longjmp 그리고 직간접의 recursion은 사용하지 않는다.

향상된 code clarity

Rule 2 All loops must have a fixed upper-bound

Rule 3 Do not use dynamic memory allocation after initialization

Memory allocator and garbage collectors often have unpredictable behavior that can significantly impact performance.

Rule 4 No function should be longer than what can be printed on a single sheet of paper

60 lines of code per function

Rule 5 The assertion density of the code should average to a minimum of two assertions per function

Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explict recovery action must be taken(returning error condition to the caller of the function)

Rule 6. Data object must be declared at the smallest possible level of scope

Prefer local and static rather than Global

The rule discourages the re-use of variables for multiple, incompatible purposes, which can complicated fault diagnosis.

Rule 7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function

Rule 8. The use of preporcessor must be limited to the inclusion of header files and simple macro definitions.

Token pasting, variable argument lists, and recursive macro calls are not allowed.

The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilderplate that avoids multiple inclusion of the same header file.

(boilerplate : Boilerplate (spaceflight), non-functional craft, system, or payload which is used to test various configurations and basic size, load, and handling characteristics)

The c preprocessor is a powerful obfuscation tool that can destroy code clarity and befubble many text based checkers.

10 conditional compilation directives, there could be up to 2^10 possible versions of the code

Rule 9. The use of pointers should be restricted. Specifically, no more one level of dereference is allowed. Function pointers are not permitted.

Rule 10. All code must be compiled, from the fist day of development, with all compiler warnings enabled at the compiler’s most pedantic settings.

There simply is no excuse for any software development effort not to make use of this readily available technology. It should be considered routine practices, even for non-critical code development. Many devlopers have been caught in the assumption that a warning was surely invalid, only to realize much later that the message was in fact valid for less obvious reasons.

Rule 1~2 gurantees the creation of a clear and trasnparent control flow structure that is easier to build, test and anazyze