High quality code is portable, readable, clear and unambiguous. This document defines a set of rules for the production of high quality C++ code. An explanation is provided for each rule. Each rule shall be enforced unless a formal deviation is recorded. Note that Rule 2.1 outlines the process for deviation where this is deemed necessary. The guiding principles of this standard are maintenance, portability, readability and safety. This standard adopts the view that restrictions should be placed on the ISO C++ language standard in order to limit the flexibility it allows. This approach has the effect of minimising problems created either by compiler diversity, different programming styles, or dangerous/confusing aspects of the language. Different compilers may implement only a subset of the ISO C++ standard or interpret its meaning in a subtly different way that can lead to porting and semantic errors. Without applying good standards, programmers may write code that is prone to bugs and/or difficult for someone else to pick up and maintain.
Throughout this document, a rule is formatted using the following structure.
| Rule | This statement describes a rule for C++. Adherence is mandatory. |
| Guideline | This statement describes a guideline for C++. Adherence is recommended. |
| Justification | This paragraph explains the rationale behind the rule or guideline. |
| Exception | This paragraph explains cases where the rule or guideline does not apply. |
| Exclusive with | This section lists references to rules or guidelines that should be disabled if this rule or guideline is selected. |
| See also | This section lists references to rules or guidelines that are relevant to the current rule or guideline. |
| Reference | This section lists sources of relevant material. |
| 'code' | C++ keywords and code items are shown in single quotes in the text. |
This standard aims to enforce current best practice in C++ development by applying semantic and stylistic recommendations, including controlling the use of language features of C++ which can lead to misunderstanding and/or errors. In each case a justification is presented as to why the restriction is being applied. However, in view of the fact that research into usage of languages in general and C++ in particular is ongoing, this standard will be reviewed and updated from time to time to reflect current best practice in developing reliable C++ code.
The Base Standard for this document is the ISO/IEC C++ Standard 14882 with no extensions allowed and further restrictions as detailed in the rules.
This Standard requires that the use of the C++ language shall be further restricted, so that no reliance on statically detectable undefined or unspecified behaviour listed in this standard is allowed. Coding practice that results in undefined behaviour is dangerous and must always be avoided. Where undefined behaviour can be identified statically, coding rules limit the potential for introducing it. The rules also prohibit practice which, although well defined, is known to cause problems.
In general, only ISO C++ compliant compilers should be used. However, at the current time, compilers do not achieve full ISO compliance, and It may be some time before the mainstream compilers become completely ISO C++ compliant. Hence only the features of a compiler that are proven to be ISO C++ compliant should be used. Compiler validation is a useful way to gauge the compliance of a compiler with the ISO C++ standard.
Some of the rule in this standard are mutually exclusive, hence only a subset of rules should be selected from this standard.
Requirements in this standard express:
The basis of these requirements is that by meeting them it is possible to avoid known problems and thereby reduce the incidence of errors.
The rules in this standard refer directly to inconsistencies which can arise within a single translation unit, i.e. a file which is being checked or compiled. In C++, owing to its independent compilation model, many such inconsistencies arise across file boundaries, (this standard includes inter translation unit rules).
The embedding of code in languages other than C++ within C++ code is forbidden unless accompanied by a written justification for its use. The generally poor definition of interfaces to embedded, non C++ code, can lead to problems. Any necessary use should therefore be localised as much as possible. Embedded code for pre-processors other than the Standard C++ pre-processor shall be similarly restricted.
Notwithstanding the requirements of this standard, it may be necessary, and in some cases desirable to tolerate limited non-compliance. Such non-compliance shall, without exception, be the subject of a written deviation supported by a written justification.
Good practice advocates using a compliance matrix to accompany all C++ development projects. A compliance matrix shall detail the following information about the project.
Such a matrix should be laid out as a simple table.
For example:
| Description of Development | Edge-detection algorithm library |
| Compiler release | GNU compiler version x.x.x.x |
| Compiler validation status | Yes; ISO |
| Compiler switches | ... |
| ... | ... |
| ... | ... |
The following sections comprise the rules to be followed for C++ code. These rules are largely supported by the High Integrity C++ Compliance Module (HICPPCM-2.4-QACPP-2.3) provided by Programming Research for the QAC++ static analyser.
This section provides some guidance on the future direction of this standard as this may affect the way you currently program. It lists Rules and Guidelines which are marked for review in subsequent editions of this standard. This means that items mentioned here may be promoted to Rules, demoted to Guidelines or dropped altogether.
No issues in this release.
| Functor | Object created from a functor class. Also known as a functor object. |
| Functor class | Any class that overloads the function call operator (operator() ) is a functor class. |
| POD |
An acronym for Plain Old Data. A POD-struct is 'an aggregate class that has no non-static
data members of type pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assignment operator and no user-defined
destructor.'
A POD-union is 'an aggregate union that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor.' A POD-class is a class that is either a POD-struct or a POD-union. Arithmetic types, enumeration types, pointer types, and pointer to member types are collectively called scalar types. Scalar types, POD-class types, and arrays of such types are collectively called POD types. |
| Predicate | A predicate is a function that returns either bool or a type that can be implicitly converted to bool. |
| Predicate class | A predicate class is a functor class whose operator() function is a predicate, i.e. its operator() returns true or false. |
| [Stroustrup, 2000] | Bjarne Stroustrup: The C++ Programming Language. Addison-Wesley. 2000 |
| [C++ Standard, 1999] | International Standard ISO/IEC 14882:1998(E) Programming Language C++. |
| [Effective C++, 1996] | Scott Meyers: Effective C++. Addison-Wesley. 1996 |
| [More Effective C++, 1996] | Scott Meyers: More Effective C++. Addison-Wesley. 1996 |
| [Effective STL, 2001] | Scott Meyers: Effective STL. Addison-Wesley. 2001 |
| [Industrial Strength C++, 1997] | Mats Henricson, Erik Nyquist, Ellemtel Utvecklings AB: Industrial Strength C++. Prentice Hall. 1997 |