The expectation is that users of this document will develop and use a coding standard based on this document that is tailored to their risk environment.
Number
|
Recommended avoidance mechanism
|
References
|
1
|
Validate input. Do not make assumptions about the values of parameters. Check parameters for valid ranges and values in the calling and/or called functions before performing any operations.
|
6.6 7.13
7.18
7.28
|
2
|
Where functions return error values, check the return values before processing any other returned data.
|
6.36
6.60
|
3
|
Enable compiler static analysis checking and resolve compiler warnings.
|
6.8 6.10 6.14 6.15
6.16 6.17 6.18 6.19
6.22 6.25 6.26 6.27
6.29 6.30 6.34 6.36
6.38 6.39 6.47 6.54
6.56 6.57 6.60 6.61
6.62 7.28.
|
4
|
Run a static analysis tool to detect anomalies not caught by the compiler.
|
6.3 6.6 6.7 6.8
6.10 6.14 6.15 6.16
6.17 6.18 6.19 6.22
6.25 6.26 6.27 6.29
6.30 6.34 6.36 6.38
6.39 6.47 6.54 6.56
6.57 6.60 6.61 6.62
7.28
|
5
|
Perform explicit range checking when it cannot be shown statically that ranges will be obeyed, when range checking is not provided by the implementation, or if automatic range checking is disabled.
|
6.6
6.8
6.16
|
6
|
Allocate and free memory at the same level of abstraction.
|
6.14
|
7
|
Test constructs that have unspecified behavior for all possible behaviours.
|
6.24 6.56
|
8
|
Make error detection, error reporting, error correction, and recovery an integral part of a system design.
|
6.36
|
10
|
Use only those features of the programming language that enforce a logical structure on the program.
|
6.31
|
11
|
Avoid using features of the language which are not specified to an exact behaviour or that are undefined, implementation-defined or deprecated.
|
6.55 6.56
6.57 6.58
6.59
|
12
|
Avoid using libraries without proper signatures.
|
6.34
|
13
|
Do not modify loop control variables inside the loop body.
|
6.29
|
14
|
Do not perform assignments within Boolean expressions, where possible in the language system.
|
6.25
|
15
|
Do not depend on side-effects of a term in the expression itself.
|
6.31 6.24 (check)
|
16
|
Use names that are clear and visually unambiguous. Be consistent in choosing names.
|
6.17
|
17
|
Use careful programming practice when programming border cases.
|
6.6 6.29
6.30
|
18
|
Be aware of short-circuiting behaviour when expressions with side effects are used on the right side of a Boolean expression such as if the first expression evaluates to false in an and expression, then the remaining expressions, including functions calls, will not be evaluated.
|
6.24
6.25
|
19
|
Avoid fall-through from one case (or switch) statement into the following case statement: if a fall-through is necessary then provide a comment to inform the reader that it is intentional.
|
6.27
|
20
|
Do not use floating-point arithmetic when integers or booleans would suffice, especially for counters associated with program flow, such as loop control variables.
|
6.4
|
21
|
Sanitize, erase or encrypt data that will be visible to others (for example, freed memory, transmitted data).
|
7.11
7.12
|