High Integrity C++ (HIC++) Coding Standard — 155 High C++ Coding Rules

High Integrity C++ Is a Coding Standard Developed By Experts at PRQA (Now Part of Perforce).

October 3, 2013 was the 10th anniversary of High Integrity C++ (HIC++), one of the longest established and most respected coding standards for C++, with a major update that extends its scope to cover C++11 and beyond.

Over the past decade, the HIC++ coding standard had been downloaded a staggering 25,000 times — a clear endorsement by the development community that recognizes HIC++ as a key source of coding rules and best practices, enabling the production of high C++ quality code.

“The growing importance of coding standards has been one of the most significant trends impacting the test tool space over the past several years. And HIC++ is one of the most widely adopted.”
—Chris Rommel, Vice President, M2M Embedded Technology at VDC

In Version 4.0 of HIC++:

The overall number rules has been reduced from 202 to 155.
80 rules have been retired and 44 have been merged to 16.
61 new rules have been added, mostly related to C++11, (lambdas, rvalue references, concurrency enhancements), but also covering other best practices.
All rules receive improved explanations including compliant and non-compliant code examples.

Introduction

This document defines a set of rules for the production of high quality C++ code¹. The guiding principles of this standard are maintenance, portability, readability, and robustness. Justification with examples of compliant and/or non-compliant code are provided for each rule. Each rule shall be enforced unless a formal deviation is recorded (see Section 0.6).

This standard adopts the view that restrictions should be placed on the use of the ISO C++ language (see 1.1.1) without sacrificing its core flexibility. This approach allows for the creation of robust and easy to maintain programs while minimizing problems created either by compiler diversity, different programming styles, or dangerous/confusing aspects of the language.

Without applying good coding standards, programmers may write code that is prone to bugs or difficult for someone else to pick up and maintain.

A combination of techniques has to be applied to achieve high integrity software: e.g. requirements management and coverage testing. Only a few of such techniques are programming language specific, of which language subsetting is widely regarded as an effective and scalable method. When rigorously enforced, and coupled with language agnostic techniques, it can facilitate production of high integrity C++ code.

¹ Rules have been selected based on their applicability to any project written using the C++ Language. Users of this standard may need to consider additional domain specific rules appropriate to their project.

0.1 Typographical Conventions

Throughout this document, a rule is formatted using the following structure.

X.Y.Z	This statement describes a rule for C++. Adherence is mandatory. Text immediately below the rule heading provides rationale and example(s).
Exception:	This paragraph explains cases where the rule does not apply.
References:	This section lists sources of relevant material or related rules.
QA·C++ 3.1 Enforcement:	This section details automated enforcement of the rule.
keyword	C++ keywords and code items are shown in monospace font and blue color.
term	Terms defined in the C++ Standard appear italicized, see Section 0.7.

0.2 Escalation policy

This coding 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 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 coding standard will be reviewed and updated from time to time to reflect current best practice in developing reliable C++ code.

0.3 Base Standard and Policy

0.3.1 ISO Standard C++
The base standard for this document is as specified in 1.1 with no extensions allowed and further restrictions as detailed in the rules.

0.3.2 Statically detectable restrictions
This coding standard requires that the use of the C++ language shall be further restricted, so that no reliance on statically detectable² undefined or unspecified behavior listed in the ISO C++ Standard is allowed. Where undefined behavior 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.
² i.e., at compile time

0.3.3 Examples
This standard contains many example code fragments which are designed to illustrate the meaning of the rules. For brevity some of the example code does not conform to all best practices, e.g. unless the rule relates explicitly to concurrency, the example code may not be thread-safe.

0.4 Basis of requirements

Requirements in this standard express restrictions on the use of language constructs or library functions that:

Are not completely defined by the ISO C++ Standard.
Permit varied compiler interpretation.
Are known to be frequently misunderstood or misused by programmers thereby leading to errors.
Do not follow established best practice.

The basis of these requirements is that by meeting them it is possible to avoid known problems and thereby reduce the incidence of errors.

0.5 Rule Enforcement

For any non-trivial code base, manual enforcement of rules in this coding standard will be time consuming and unreliable. Therefore, automated enforcement should be used when possible.

Rules in this coding standard that constrain the value of an expression are undecidable in the computer theoretical sense, because compliance is in general dependent on variables (program state). These rules are identified by the word ’demonstrably’ appearing in their headline. However, a program can be augmented with code guards (e.g. assertion statements), to make enforcement decidable, by constraining the value of the expression to guarantee compliance. Conversely, if the value of the expression is not suitably guarded, the code is non-compliant. For an example, see Rule 4.2: "listing".

0.6 Deviations

Notwithstanding the requirements of this coding 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.

0.7 Glossary

term	C++11 ref	explanation

captured by copy	5.1.2	entity captured by a lambda implicitly or explicitly by copy
captured by reference	5.1.2	entity captured by a lambda implicitly or explicitly by reference
function try block	15	a function body which is a try block
lambda-declarator	5.1.2	analogue of function prototype for lambdas
lvalue	3.10	a function or a non-temporary object
one definition rule (ODR)	3.2	places restrictions on multiple definitions of variables, functions, templates and user defined types
ODR use	3.2	for a const object occurs when the object is used as an lvalue, e.g. as an operand of the unary & (address of) operator
rvalue	3.10	a temporary object or a value not associated with an object
lvalue reference	8.3.2, 8.5.3	a reference type declared using &
rvalue reference	8.3.2, 8.5.3	a reference type declared using &&
sequenced before	1.9	establishes a partial order on evaluations executed by a single thread
static initialization	3.6.2	zero-initialization or constant initialization of an object with static or thread storage duration
using declaration	7.3.3	introduces the specified name into the current scope, e.g. using std::vector;
using directive	7.3.4	allows all names from the specified namespace to be used in the current scope, e.g. using namespace std;

General

1.1 Implementation Compliance

1.1.1 Ensure that code complies with the 2011 ISO C++ Language Standard
The current version of the C++ language is as defined by the ISO International Standard ISO/IEC 14882:2011(E) “Information technology — Programming languages — C++”.

Compilers often provide features beyond those defined in the Standard, and unrestricted sage of such features will likely hamper code portability. To this end, source code should be routinely parsed with a separate compiler or code analysis tool apart from the compiler used for production purposes.

#include <cstdint>
void foo (int32_t i)
{
int32_t * a;

__try // @@- Non-Compliant [email protected]@
{
a = new int32_t [i];

// ...
}
__finally // @@- Non-Compliant [email protected]@
{
delete [] a;
}
}

References

HIC++ v3.3 – 1.3.1
HIC++ v3.3 – 6.4
HIC++ v3.3 – 13.3
Meyers Notes – Reference Binding Rules

Trigraph	Equivalent	Digraph	Equivalent
??=	#	%:%:	##
??(	[	%:	#
??<	{	<:	[
??)	]	<%	{
??>	}	:>	]
??/	\	%>	}
??’	ˆ
??!	\|
??-	~

CERT C++	CERT C++ Secure Coding Standard
C++11	The ISO C++ Language Standard ISO/IEC 14882:2011
C++98	The ISO C++ Language Standard ISO/IEC 14882:1998
Going Native 2013	Stephan T. Lavavej: GoingNative 2013: Don’t Help the Compiler
HIC++ v3.3	High Integrity C++ Coding Standard Manual – Version 3.3, September 2012, Programming Research
JSF AV C++ Rev C	Joint Strike Fighter Air Vehicle C++ Coding Standards, December 2005, Lockheed Martin Corporation
Meyers Effective C++ ’11 (draft TOC)	Scott Meyers: Draft TOC for Effective C++11 Concurrency Chapter
Meyers Notes	Scott Meyers: Overview of The New C++ (C++11/14), July 2013
MISRA C++:2008	MISRA C++:2008 Guidelines for the use of the C++ language in critical systems, June 2008, MIRA Limited
Sutter Hardware	Herb Sutter: The C++ Memory Model and Modern Hardware
Sutter Concurrency	Herb Sutter: Effective Concurrency Columns, August 2007 – September 2010, Dr. Dobb’s Journal
Sutter Guru of the Week (GOTW)	Herb Sutter: Guru of the Week
Williams Concurrency	Anthony Williams: C++ Concurrency in Action – Practical Multithreading, 2012, Manning Publications Co.

Issue	Date
1.0	3 October 2003
2.0	20 October 2003
2.1	24 October 2003
2.2	18 May 2004
2.3	6 October 2006
2.4	14 December 2006
3.0	24 January 2008
3.1	15 February 2008
3.2	3 October 2008
3.3	25 September 2012
4.0	3 October 2013

	O(o)	0
	I(i)	l(L) 1
	S(s)	5
	Z(z)	2
	n(N)	h
	B(b)	8

High Integrity C++ Coding Standard

High Integrity C++ Is a Coding Standard Developed By Experts at PRQA (Now Part of Perforce).

HIC++ Version 4.0 Contents

Introduction

0.1 Typographical Conventions

0.2 Escalation policy

0.3 Base Standard and Policy

0.4 Basis of requirements

0.5 Rule Enforcement

0.6 Deviations

0.7 Glossary

General

1.2 Redundancy

1.3 Deprecated Features

Lexical Conventions

2.1 Character Sets

2.2 Trigraph Sequences

2.3 Comments

2.4 Identifiers

2.5 Literals

Basic Concepts

3.1 Scope

3.2 Program and Linkage

3.3 Storage Duration

3.4 Object Lifetime

3.5 Types

Standard Conversions

4.1 Array-to-Pointer Conversion

4.2 Integral Conversions

4.3 Floating Point Conversions

4.4 Floating-Integral Conversions

Expressions

5.1 Primary Expressions

5.2 Postfix Expressions

5.3 Unary Expressions

5.4 Explicit Type Conversion

5.5 Multiplicative Operators

5.6 Shift Operators

5.7 Equality Operators

5.8 Conditional Operator

Statements

6.1 Selection Statements

6.2 Iteration Statements

6.3 Jump Statements

6.4 Declaration Statement

Declarations

7.1 Specifiers

7.2 Enumeration Declarations

7.3 Namespaces

7.4 Linkage Specifications

7.5 The asm Declaration

Definitions

8.1 Type Names

8.2 Meaning of Declarators

8.3 Function Definitions

8.4 Initializers

Classes

9.1 Member Functions

9.2 Bit-fields

Derived classes

10.1 Multiple Base Classes

10.2 Virtual Functions

10.3 Abstract Classes

Member Access Control

11.1 Access Specifiers

11.2 Friends

Special Member Functions

12.1 Conversions

12.2 Destructors

12.3 Free Store

12.4 Initializing Bases and Members

12.5 Copying and Moving Class Objects

Overloading

13.1 Overload Resolution

13.2 Overloaded Operators

Templates

14.1 Template Declarations

14.2 Template instantiation and specialization

Exception handling

15.1 Throwing an Exception