Coding Rules
Coding rules might at
first seem similar to style rules, but should be more focused on
correctly functioning code as opposed to code readability. Coding rules
may vary, but there are some established, venerable rules that should
always apply.
An example of some coding rules follow (these
will often be influenced by the chosen programming language as well as the target application domain):
-
CR01: Avoid using multiple inheritance. If it is deemed absolutely necessary, then it must be approved by the project team lead.
-
CR02: Do not throw exceptions from a destructor.
-
CR03: Avoid using goto statements. If it is deemed absolutely necessary, then it must be approved by the project team lead.
-
CR04: Avoid using recursion. If it is deemed absolutely necessary, then it must be approved by the project team lead.
-
CR05: Handle all branching
conditions specifically. A trailing "else" of an "if-else" construct
should always be an error case. Likewise, the "default" case of a
"switch" construct should always be an error case.
-
CR06: Integer constants and
integer literals that are used as state or flag values in logical
statements must be differentiated from other flags / states in the same
set by at least three bits.
-
CR07: Never mask error codes. If an error code is returned, do not discard that code and instead return a different error code.
-
CR08: Initialize all variables at declaration.
-
CR09: Avoid using global variables. If it is deemed absolutely necessary, then it must be approved by the project team lead.
-
CR10: Serialize all access to global variables if there is any possibility of multiple threads running concurrently.
-
CR11: All functions must have only one exit or return point.
-
CR12: Always check pointers for NULL before dereferencing those pointers.
-
CR13: Ensure that parameters that are not intended to be updated by the function that is getting called are given "const" qualifiers.
Note: The above rules are specific to the C and C++ programming languages.