2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Philips C++ Coding Standard (≥C++11)

Version: 8.48
Issuer: CCB Coding Standards Philips Healthcare

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 1/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Introduction
Purpose
This document defines the Philips Healthcare C++ Coding Standard. The coding standard
consists of rules and recommendations for C++ code written and/or maintained by the Philips
Healthcare SW departments. It replaces department specific C++ coding standards [Schaick] and
[Tongeren].

Scope
The coding standard is based on the rules and recommendations of several sources. These
include "Industrial Strength C++" [ISC++], "Philips Medical Systems C Coding Standard"
[Hatton], "PMS-MR C++ Coding Standard" [Tongeren], and "CIS C++ Development Guidelines"
[Schaick].

The procedure to be followed when a rule must be broken is outside the scope of this
document. This procedure should be defined at project or department level.

This coding standard specifies rules

to prevent coding errors

to prevent coding using obsolete or deprecated language features
to prevent coding using undefined or implementation defined language features
to achieve a certain consistency in coding style

The Philips Healthcare C++ coding standard does not attempt to teach how to design effective
C++ code. It also does not categorically rule out any programming idioms that C++ is designed
to support. Background information on the rationale for C++ language design decisions are
documented in [StroustrupDE]. Applying C++ effectively is the subject of e.g. [Stroustrup], which
also lists many useful advises at the end of each chapter.

Document Layout
The coding standard document consists of a set of rules. Rules are grouped together logically
into so called categories. Each chapter deals with one category. A rule description contains the
following items:

Synopsis. This is a brief description of the rule.

Language. The language item indicates for what language(s) the rule is applicable.
Severity Level. All rules in this coding standard have a level assigned to it, ranging from 1
to 10. Level 1 concerns the most severe issues (program errors), whereas level 10 consists of
the least important rules (style issues). The rules have been distributed evenly over the
available levels to be able to focus on a certain limited set of violations.
Category. This indicates to what category a rule belongs.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 2/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Description. The description explains the rule in more detail. Sometimes it also contains a
justification of the rule, possible exceptions and code examples.
Literature References. This section contains references to the origin of the rule. It can also
be used for further reading.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 3/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Change History
8.48 2024-08-04
Paul Jansen (TIOBE): - ADS ticket 8293: Introduced rule OLC#022.
8.47 2024-07-03
Paul Jansen (TIOBE): - ADS ticket 7504: Introduced rule CON#010.
8.46 2024-06-03
Paul Jansen (TIOBE): - ADS ticket 6813: Removed rule STA#002.
8.45 2024-05-05
Paul Jansen (TIOBE): - ADS ticket 8483: Renamed rule CFL#005 to ES.43,
renamed rule CFL#019 to ES.41, renamed rule CON#002 to ES.50, renamed
rule CON#004 to ES.49, renamed rule OLC#006 to ES.5, renamed rule
OLC#010 to ES.10, renamed rule OLC#016 to ES.12, renamed rule OLC#017
to ES.20, renamed rule POR#029 to ES.44.
8.44 2024-04-14
Paul Jansen (TIOBE): - ADS ticket 7182: Introduced rule CFL#023.
8.43 2023-12-16
Paul Jansen (TIOBE): - ADS ticket 6737: Introduced rule NAM#016.
8.42 2023-10-21
Paul Jansen (TIOBE): - RTC ticket 259159: Introduced rule R.13.
8.41 2023-10-16
Paul Jansen (TIOBE): - RTC ticket 271431: Changed severity level of rule
INT#002.
8.40 2023-08-20
Paul Jansen (TIOBE): - RTC ticket 270497: Introduced rule CFL#027.
8.39 2023-08-03
Paul Jansen (TIOBE): - RTC ticket 271305: Adjusted rule F.54 according to
the latest changes in the C++ core guidelines.
8.38 2023-07-07
Paul Jansen (TIOBE): - RTC ticket 258553: Improved synopsis and
description of rule OLC#006.
8.37 2023-06-29
Paul Jansen (TIOBE): - RTC ticket 270405: Introduced rules F.50, F.53 and
F.54.
8.36 2023-05-21
Paul Jansen (TIOBE): - RTC ticket 259163: Introduced rule R.21.
8.35 2023-05-08
Paul Jansen (TIOBE): - RTC ticket 216370: Changed rule ORG#013 into F.5.
8.34 2023-04-17

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 4/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Paul Jansen (TIOBE): - RTC ticket 259162: Introduced rule R.20.

8.33 2023-03-26
Paul Jansen (TIOBE): - RTC ticket 267011: Changed rule INT#022 into F.17.
8.32 2023-03-26
Paul Jansen (TIOBE): - RTC ticket 260834: Improved description of rule
INT#028.
8.31 2023-02-11
Paul Jansen (TIOBE): - RTC ticket 267840: Improved description of rule
OAL#019.
8.30 2023-02-05
Paul Jansen (TIOBE): - RTC ticket 267658: Improved examples of rule
OAL#019.
8.29 2023-02-02
Paul Jansen (TIOBE): - RTC ticket 263765: Introduced new rule INT#031.
8.28 2023-01-30
Paul Jansen (TIOBE): - RTC ticket 259154: Introduced rule R.5.
8.27 2023-01-01
Paul Jansen (TIOBE): - RTC ticket 259152: Introduced rule R.3.
8.26 2023-01-01
Paul Jansen (TIOBE): - RTC ticket 259167: Introduced rule R.30.
8.25 2022-12-24
Paul Jansen (TIOBE): - RTC ticket 257776: Changed severity level of rule
C.21.
8.24 2022-12-06
Paul Jansen (TIOBE): - RTC ticket 264095: Replaced rule OOP#001 by C.21.
8.23 2022-12-06
Paul Jansen (TIOBE): - RTC ticket 259151: Introduced rule R.2.
8.22 2022-12-05
Paul Jansen (TIOBE): - RTC ticket 259161: Replaced rule OAL#003 by R.15.
8.21 2022-09-23
Paul Jansen (TIOBE):
- RTC ticket 261598: Replaced rule CFL#026 by CP.42.
8.20 2022-09-23
Paul Jansen (TIOBE):
- RTC ticket 259157: Replaced rule OAL#011 by R.11.
8.19 2022-08-28
Paul Jansen (TIOBE):
- RTC ticket 259171: Improved synopsis of rule R.34.
8.18 2022-08-28

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 5/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Paul Jansen (TIOBE):

- RTC ticket 259171: Introduced new rule R.34.
8.17 2022-08-28
Paul Jansen (TIOBE):
- RTC ticket 259165: Introduced new rule R.23.
8.16 2022-07-24
Paul Jansen (TIOBE):
- RTC ticket 220484: Replaced rule OOP#013 by C.127.
8.15 2022-07-24
Paul Jansen (TIOBE):
- RTC ticket 157407: Introduced new rule OAL#019.
8.14 2022-06-28
Paul Jansen (TIOBE):
- RTC ticket 259155: Introduced new rule I.2.
8.13 2022-06-28
Paul Jansen (TIOBE):
- RTC ticket 259174: Introduced new rule R.37.
8.12 2022-06-07
Paul Jansen (TIOBE):
- RTC ticket 259172: Introduced new rule R.35.
8.11 2022-05-22
Paul Jansen (TIOBE):
- RTC ticket 259164: Introduced new rule R.22.
8.10 2022-05-15
Paul Jansen (TIOBE):
- RTC ticket 259170: Introduced new rule R.33.
8.9 2022-04-22
Paul Jansen (TIOBE):
- RTC ticket 258257: Fixed the examples of rule CFL#026.
8.8 2022-03-27
Paul Jansen (TIOBE):
- RTC ticket 252840: Set rule INT#006 to a lower severity level.
8.7 2022-01-30
Paul Jansen (TIOBE):
- RTC ticket 242219: Improved description of rule PCA#002.
8.6 2021-11-15
Paul Jansen (TIOBE):
- RTC ticket 213570: Improved synopsis and description of rule INT#023.
8.5 2021-11-15

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 6/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Paul Jansen (TIOBE):

- RTC ticket 245961: Improved description of rule OAL#011.
8.4 2021-11-01
Paul Jansen (TIOBE):
- RTC ticket 213569: Removed rule INT#014.
8.3 2021-09-12
Paul Jansen (TIOBE):
- RTC ticket 243781: Improved synopsis and description of rule PCA#010.
8.2 2021-08-29
Paul Jansen (TIOBE):
- RTC ticket 228914: Extended rule OOP#001.
8.1 2021-06-12
Paul Jansen (TIOBE):
- RTC ticket 236515: Improved synopsis of rule INT#027.
8.0 2021-04-11
Paul Jansen (TIOBE):
- RTC ticket 225748: Removed all security rules from the coding standard.
7.51 2021-04-06
Paul Jansen (TIOBE):
- RTC ticket 222870: Improved description of rule POR#021.
7.50 2021-03-28
Paul Jansen (TIOBE):
- RTC ticket 219448: Resurrected rule INT#026.
7.49 2021-02-21
Paul Jansen (TIOBE):
- RTC ticket 221066: Improved rule PCA#010.
7.48 2020-12-27
Paul Jansen (TIOBE):
- RTC ticket 218579: Removed rule CON#008.
7.47 2020-11-22
Paul Jansen (TIOBE):
- RTC ticket 216363: Improved rule OOP#004.
7.46 2020-10-11
Paul Jansen (TIOBE):
- RTC ticket 157411: Introduced new rule PCA#019.
7.45 2020-09-28
Bram Stappers (TIOBE):
- Redmine 26637: Fixed encoding portability issues for rules ERR#014,
OLC#021, OOP#013, ENV33-C, and MSC33-C.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 7/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

7.44 2020-09-25
Paul Jansen (TIOBE):
- RTC ticket 216366: Relaxed rule PCA#010.
7.43 2020-09-14
Paul Jansen (TIOBE):
- RTC ticket 213572: Removed rule INT#026.
7.42 2020-09-08
Paul Jansen (TIOBE):
- RTC ticket 213576: Removed rule CFL#020.
7.41 2020-09-05
Paul Jansen (TIOBE):
- RTC ticket 194061: Adjusted severity level of rule COM#002.
7.40 2020-09-02
Paul Jansen (TIOBE):
- RTC ticket 216368: Extended description of rule PCA#016.
7.39 2020-08-28
Paul Jansen (TIOBE):
- RTC ticket 50967: Adjusted severity level of rule PCA#011.
7.38 2020-08-17
Paul Jansen (TIOBE):
- RTC ticket 213575: Improved description of rule CFL#018.
7.37 2020-08-12
Paul Jansen (TIOBE):
- RTC ticket 210048: Removed rule PCA#007.
7.36 2020-08-12
Paul Jansen (TIOBE):
- RTC ticket 216364: Removed rule OOP#005.
7.35 2020-08-03
Paul Jansen (TIOBE):
- RTC ticket 212951: Improved rule OOP#013.
7.34 2020-08-03
Paul Jansen (TIOBE):
- RTC ticket 207470: Improved synopsis of rule OLC#018.
7.33 2020-07-11
Paul Jansen (TIOBE):
- RTC ticket 213577: Improved synopsis and description of rule OAL#018.
7.32 2020-07-10
Paul Jansen (TIOBE):
- RTC ticket 213578: Improved synopsis of rule OLC#005.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 8/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

7.31 2020-07-08
Paul Jansen (TIOBE):
- RTC ticket 213578: Improved rule OLC#005.
7.30 2020-06-26
Paul Jansen (TIOBE):
- RTC ticket 204299: Introduced new rule CFL#026.
7.29 2020-06-21
Paul Jansen (TIOBE):
- RTC ticket 205613: Removed rule STY#004.
7.28 2020-06-19
Paul Jansen (TIOBE):
- RTC ticket 211070: Added descriptions to rules ERR#014 and ERR#016.
7.27 2020-06-08
Paul Jansen (TIOBE):
- RTC ticket 163635: Improved example of rule ERR#012.
7.26 2020-05-26
Paul Jansen (TIOBE):
- RTC ticket 66575: Improved rule INT#021.
7.25 2020-05-25
Paul Jansen (TIOBE):
- RTC ticket 161598: Introduced new rule CON#009.
7.24 2020-05-25
Paul Jansen (TIOBE):
- RTC ticket 197688: Extended rule STY#029.
7.23 2020-05-21
Paul Jansen (TIOBE):
- RTC ticket 201352: Removed rule CFL#022.
7.22 2020-04-14
Paul Jansen (TIOBE):
- RTC ticket 205392: Improved rule PCA#018 and removed rule OAL#017.
7.21 2020-03-21
Paul Jansen (TIOBE):
- RTC ticket 205339: Allowed constants for rule ORG#013.
7.20 2020-03-17
Paul Jansen (TIOBE):
- RTC ticket 196169: Introduced new rule CFL#025.
7.19 2020-02-28
Paul Jansen (TIOBE):
- RTC ticket 201898: Removed rule PCA#013.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLpR… 9/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

7.18 2020-01-12
Paul Jansen (TIOBE):
- RTC ticket 167009: Removed rule OLC#008.
7.17 2020-01-05
Paul Jansen (TIOBE):
- RTC ticket 66583: Introduced new rule PCA#018.
7.16 2019-09-16
Paul Jansen (TIOBE):
- RTC ticket 97108: Removed rule OAL#005.
7.15 2019-08-10
Paul Jansen (TIOBE):
- RTC ticket 117848: Removed rule OLC#002.
7.14 2019-08-07
Paul Jansen (TIOBE):
- RTC ticket 185511: Improved rule PCA#007.
7.13 2019-07-21
Paul Jansen (TIOBE):
- RTC ticket 117847: Removed rule OAL#015.
7.12 2019-07-14
Paul Jansen (TIOBE):
- RTC ticket 86087: Improved description of rule OOP#013.
7.11 2019-05-26
Paul Jansen (TIOBE):
- RTC ticket 117850: Improved rule OLC#009.
7.10 2019-03-04
Paul Jansen (TIOBE):
- RTC ticket 66581: Improved description of rule PCA#001.
7.9 2019-03-03
Paul Jansen (TIOBE):
- RTC ticket 82230: Generalized rule GEN#002.
7.8 2019-02-25
Paul Jansen (TIOBE):
- RTC ticket 85004: Extended rule OLC#020 for base types.
7.7 2019-02-02
Paul Jansen (TIOBE):
- RTC ticket 124664: Improved description of rule ORG#011.
7.6 2019-01-27
Paul Jansen (TIOBE):
- RTC ticket 49970: Introduced new rule OAL#018.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 10/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

7.5 2018-12-23
Paul Jansen (TIOBE):
- RTC ticket 117846: Removed rule CFL#013.
7.4 2018-12-15
Paul Jansen (TIOBE):
- RTC ticket 166687: Improved description of rule OLC#021.
7.3 2018-11-19
Paul Jansen (TIOBE):
- RTC ticket 103876: Introduced new rule OAL#017.
7.2 2018-10-28
Paul Jansen (TIOBE):
- RTC ticket 117844: Adjusted rule CFL#011.
7.1 2018-10-28
Paul Jansen (TIOBE):
- RTC ticket 84409: Removed rules OAL#007, OAL#008 and generalized
rule OAL#011.
7.0 2018-10-28
Rob Douma (Philips)/Paul Jansen (TIOBE):
- RTC ticket 158629: Added security rules ARR38-C, DCL50-CPP, ENV33-C,
ERR33-C, ERR54-CPP, EXP34-C, EXP53-CPP, EXT01-CPP, EXT02-CPP,
EXT03-CPP, EXT04-CPP, EXT05-CPP, FIO30-C, FIO34-C, FIO37-C, FIO45-C,
MEM50-CPP, MEM56-CPP, MSC30-C, MSC33-C, MSC51-CPP, STR31-C,
STR32-C, STR38-C, STR50-CPP and STR51-CPP.
6.22 2018-09-03
Paul Jansen (TIOBE):
- RTC ticket 81705: Removed rule POR#036.
6.21 2018-08-13
Paul Jansen (TIOBE):
- RTC ticket 138794: Improved synopsis of rule OLC#021.
6.20 2018-08-13
Paul Jansen (TIOBE):
- RTC ticket 138794: Added new rule OLC#021.
6.19 2018-07-26
Paul Jansen (TIOBE):
- RTC ticket 154519: Adjusted severity level for rule ERR#012.
6.18 2018-07-25
Paul Jansen (TIOBE):
- RTC ticket 144003: Removed all references to the ISC++ and Ellemtel
standards.
6.17 2018-07-25

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 11/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Paul Jansen (TIOBE):

- RTC ticket 90693: Improved description of rule PCA#002.
6.16 2018-04-10
Paul Jansen (TIOBE):
- RTC ticket 76091: Introduced new rule PCA#017.
6.15 2018-03-03
Paul Jansen (TIOBE):
- RTC ticket 137163: Improved synopsis, description and definition of rule
INT#027.
6.14 2018-02-15
Paul Jansen (TIOBE):
- RTC ticket 117838: Improved synopsis, description and definition of rule
CFL#019.
6.13 2018-01-04
Paul Jansen (TIOBE):
- RTC ticket 127759: Improved the description of rule OLC#005.
6.12 2017-12-30
Paul Jansen (TIOBE):
- RTC ticket 117843: Improved synopsis, description and definition of rule
CFL#009.
6.11 2017-06-25
Paul Jansen (TIOBE):
- RTC ticket 47077: Improved synopsis and description of rule CFL#014.
6.10 2017-06-25
Paul Jansen (TIOBE):
- RTC ticket 29011: Replaced the term "include file" by "header file".
6.9 2017-05-15
Paul Jansen (TIOBE):
- RTC ticket 81703: Added exception to rule NAM#008.
- RTC ticket 82228: Improved synopsis of rule CFL#020.
6.8 2017-05-14
Paul Jansen (TIOBE):
- RTC ticket 109536: Improved rule ERR#012.
6.7 2017-05-04
Paul Jansen (TIOBE):
- RTC ticket 66575: Improved rule INT#021.
6.6 2017-03-29
Paul Jansen (TIOBE):
- RTC ticket 47083: Removed rule ERR#002.
- RTC ticket 63275: Added exception to rule CFL#002.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 12/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

- RTC ticket 66579: Improved description of rule OOP#001.

- RTC ticket 66582: Improved description of rule STY#020.
- RTC ticket 84425: Removed rule POR#035.
- RTC ticket 95342: Added rule OAL#015.
6.5 2017-03-21
Paul Jansen (TIOBE):
- RTC ticket 82229: Changed synopsis of rule CON#008.
6.4 2017-02-21
Paul Jansen (TIOBE):
- RTC ticket 88854: Extended rule INT#027.
6.3 2017-01-27
Paul Jansen (TIOBE):
- RTC ticket 91090: Removed rule STY#018.
6.2 2016-12-25
Paul Jansen (TIOBE):
- RTC ticket 94331: Changed all occurrences of NULL by nullptr.
6.1 2016-02-11
Paul Jansen (TIOBE)
- RTC ticket 72958: Resurrected rule CFL#024.
6.0 2015-08-27
Paul Jansen (TIOBE)
- RTC ticket 45178: Added rules OAL#011, OAL#012, OAL#013.
- RTC ticket 45178: Improved rule OAL#008 to conform to RAII.
- RTC ticket 47076: Extended rule INT#027 with keyword override.
- RTC ticket 47081: Added exception of smart pointers to CFL#011 and
CON#007.
- RTC ticket 47085: Revised rule ERR#006 to conform to C++11.
- RTC ticket 47087: Removed rule ERR#010.
- RTC ticket 49185: Introduced the swap idiom for rule OLC#002.
- RTC ticket 50551: Improved rule CFL#018 to use the C++11 range-based
for loop.
- RTC ticket 50555: Changed rule POR#032 to use the C++11 nullptr
keyword.
- RTC ticket 50557: Improved rule OAL#004 to be compliant with C++11.
- RTC ticket 50558: Changed rule OLC#001 to conform to C++11.
- RTC ticket 50559: Removed rule OOP#006.
- RTC ticket 50560: Changed rule STY#020 to conform to C++11.
- RTC ticket 50562: Introduced rule PCA#016.
5.8 2015-03-23

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 13/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Paul Jansen (TIOBE)

- RTC-51109: improved description of rule OLC#004.
5.7 2015-01-05
Paul Jansen (TIOBE)
- RTC-46173: removed rule OAL#006 and extended rule OAL#007.
5.6 2014-11-11
Paul Jansen (TIOBE)
- Made rule INT#006 checkable.
5.5 2014-10-06
Paul Jansen (TIOBE)
- Fixed typos in description of rule CON#004.
5.4 2014-09-25
Paul Jansen (TIOBE)
- RTC-42457: added rule ORG#012.
5.3 2014-03-31
Paul Jansen (TIOBE)
- RTC-30209: removed rule INT#020.
5.2 2013-11-17
Paul Jansen (TIOBE)
- Made rule CFL#019 checkable.
5.1 2013-11-12
Paul Jansen (TIOBE)
- RTC-11329: made rule CON#007 checkable.
- RTC-19317: allowed UK English as well for rule COM#003.
5.0 (Authorized) 2013-01-22
Paul Jansen (TIOBE)
- Processed review comments.
- RTC-2529: added rule CON#008.
- RTC-11836: removed functions from rule PRE#001 and changed severity
level.
4.1 2012-11-01
Paul Jansen (TIOBE)
- RTC-1424: changed rule CFL#016 to use cyclomatic complexity.
- RTC-6472: added a rationale to rule POR#025.
- RTC-6982: added an exception for "stdafx.h" to rule ORG#005.
- RTC-6983: removed rule PCA#012.
- RTC-6985: added a rationale to rule CON#006.
- RTC-8478: introduced new rule POR#038.
- RTC-9098: added built-in type conversions to rule CON#004 and
improved its description.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 14/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

- RTC-10095: removed the following rules as discussed by the C++ coding

standards refresh team: CFL#003, CFL#008, CFL#010, CFL#012, CFL#015,
CFL#021, CFL#023, CFL#024, COM#001, COM#004, COM#007, CON#003,
CON#005, ERR#004, ERR#007, ERR#008, ERR#009, ERR#013, GEN#001,
GEN#003, INT#003, INT#004, INT#005, INT#007, INT#009, INT#012,
INT#013, INT#016, INT#017, INT#018, INT#019, INT#024, INT#025,
NAM#001, NAM#004, NAM#006, NAM#007, NAM#009, NAM#010,
NAM#011, NAM#012, NAM#015, OAL#001, OAL#010, OLC#007, OLC#011,
OLC#013, OLC#014, OOP#010, OOP#012, OOP#014, OOP#015, OOP#016,
OPT#003, ORG#008, PCA#004, PCA#014, PCA#015, POR#023, POR#024,
POR#026, POR#027, POR#034, STA#003, STY#001, STY#003, STY#005,
STY#007, STY#008, STY#009, STY#010, STY#011, STY#012, STY#013,
STY#014, STY#015, STY#016, STY#019, STY#021, STY#023, STY#026,
STY#027, STY#030, STY#031.
- RTC-10095: Adapted the following rules as discussed by the C++ coding
standards refresh team: CFL#014, CFL#016, CFL#018, COM#002, CON#006,
INT#006, INT#008, INT#014, OLC#009, OLC#010, OLC#012, OLC#019,
OOP#002, OOP#005, OOP#006, OOP#007, ORG#007, PCA#009, POR#035.
4.0 (Authorized) 2012-04-26
Issam Tlili
Reworked version after review of version 3.1
3.1 2012-02-14
Issam Tlili
WI-952: adapted description of OLC#012.
WI-953: in OLC#016 aligned the C++ implementation with the C#
implementation.
WI-970: new C++ rule STY#031.
WI-984: exclude namespaces from rule STY#009.
WI-988: relax the allowed extension for include files.
WI-992: in POR#003 changed severity level to level 4.
WI-993: adapted the description in CON#001, in CON#003 removed the
second part of the description, it is already mentioned in CON#001.
WI-1002: added exception for const array definition in OLC#009.
WI-1040: adapted ERR#005 and CON#004.
WI-1057: adapted STY#012 and STY#013.
WI-1058: adapted rule for ternary operators.
WI-1003: added description for OLC#018.
WI-954: new rule INT#030.
WI-1079: adapted description of OAL#005, and removed reference to
OLC#013.
WI-1086: adapted INT#013.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 15/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

WI-1415: adapted OLC#019.

WI-1091: removed OLC#015, in CFL#023 removed reference to OLC#015.
WI-1239: new rule NAM#015, removed NAM#003, NAM#005, NAM#014
and STY#022.
3.0.1 2011-11-22
Issam Tlili
Draft, preparations for 3.1
2.4 2010-07-08
Issam Tlili
Reworked version after review of version 2.2
Set rule CFL#024 to the right Category (CFL).
2.3 2010-07-08
Issam Tlili
Reworked version after review of version 2.2
Rule STY#031 moved to CFL#24
2.2 2010-05-17
Issam Tlili
IM-TA00006832: Adapt STY#024 for include naming.
IM-TA00006738: Clarified description in POR#003.
IM-TA00006714: New rule STY#030 for useless statements.
IM-TA00006103: New rule OLC#020; don't pass member variables to the
base class in the constructor.
IM-TA00005056: Rule moved from POR#013 to GEN#003, and adapted
synopsis.
IM-TA00004284: POR#018; severity changed to level 1.
IM-TA00002758: New rule OOP#018 for overriding const member function.
IM-TA00002632: New rule INT#029; Use built-in boolean type where
possible.
IM-TA00002631 and IM-TA00002630: New rule CON#007; Do not convert
implicitly from a boolean type to a non-boolean type.
2.1 2010-05-17
Issam Tlili
IM-TA00006832: Adapt STY#024 for include naming
IM-TA00006738: Clarified description in POR#003
IM-TA00006714: Add rule for useless statements
2.0 (Authorized) 2009-04-15
Vic Henderikx
Reworked version after review of version 1.7
1.7 2009-03-18

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 16/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Vic Henderikx
IM-TA00004418: PCA#001: also forbid functions using old C-style
allocation
IM-TA00004585: NAM#005: allow m_PascalCase for member variables
IM-TA00004654: removed NAM#013; added ORG#011: always namespaces
IM-TA00005570: Added OAL#010: don't overload new or delete
IM-TA00005054: CON#004 now level 1; added CON#006 reinterpret_cast;
updated CON#001 (removed reinterpret_cast)
IM_TA00004313: OLC#017 also for pointers to all types
IM_TA00004589: ERR#017 added: catch_all must rethrow
IM_TA00004789: ORG#001: also allow #pragma once
IM_TA00004884: STY#010: remove part about repeating "virtual" or "static"
in comment
IM_TA00004891: CFL#021: non-simple types iso user defined types
IM-TA00005040: OOP#008: "in a class" --> "in a class or in a namespace"
IM-TA00004398: INT#020: use * or & for class-typed arguments; now also
for structs
IM-TA00005407: new rule POR#036: don't use parenthesis when declaring
a class variable using default constructor
IM-TA00004890: removed OLC#013 about not giving values to simple
types in destructors
1.6.1 2008-11-27
Vic Henderikx

PCA#001: also avoid functions using C-style allocators

1.5 2008-05-21
Changed PMS to Philips Healthcare for rule GEN#002
1.4 2008-04-25
Daan van der Munnik
changed PMS to Philips Healthcare
1.3 2008-04-25
Vic Henderikx
IM-TA00003860 (CON#002 set from level 1 to level 2)
IM-TA00004003 (Removed STY#028)
IM-TA00003640 (Rephrased OLC#015)
IM-TA00004004 (INT#002: Removed paragraph about naming of
members)
IM-TA00004005 (Removed INT#016)
1.2 2008-04-25
Update Philips Logo

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 17/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

1.1 2008-04-25
Initial Import from firebird to oracle

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 18/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Class Interface
F.17
Synopsis For "in-out" parameters, pass by reference to non-const
Level 4
Category Class Interface
Status Checked

INT#001
Non-copy-constructors that can be called with one argument shall be declared as
Synopsis
explicit
Level 2
Category Class Interface
Status Checked
When using constructors with single arguments, these constructors need to be declared with the
keyword explicit. This keyword prevents implicit type conversions for the arguments to the
constructor.

explicit CTestClass(SHORT nValue);

This syntax prevents an implicit conversion from the float argument in the next example, which
can cause undesirable side effects.

CTestClass TestClass = 3.2; // Does not work

This rule does not apply to copy-constructors, because they do not define type conversions. This
rule does apply to constructors with N arguments, with N or N-1 default values. See also
[Rule:OLC#007] and [Rule:CON#001].

INT#002
Synopsis Declare non-constant data members private
Level 4
Category Class Interface
Status Checked

INT#006
A member function that should not change the state of the object shall be
Synopsis
declared const
Level 5

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 19/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Category Class Interface

Status Checked
It is possible that a const method requires non-const access to some of the data members,
without changing the objects state. For example, when a lock variable (i.e. critical section) is used
to synchronize access to other data members. In this case, the lock variable should be made
mutable. See also [Rule:CON#005].

INT#008
Use constant references (const &) instead of call-by-value, unless using a basic
Synopsis
data type, a simple object or a pointer
Level 7
Category Class Interface
Status Checked
Method/function arguments are invoked according to call-by-value. This means that values are
copied with invocations to constructors and destructors as a result. This does no harm for basic
data types, simple objects and pointers, but reduces performance for complex objects. When
arguments are passed using references (call-by-reference), only the reference itself is copied.

void SetComplexObject(const ComplexObject sName); // Less efficient.

void SetComplexObject(const ComplexObject& rsName); // More efficient.

A simple object is defined as an object that has at most 5 leave basic data types. E.g. both
struct Coordinate {
int x;
int y;
int z;
};

and

class Product {
...
private:
Coordinate loc;
float price;
};

are considered simple objects in this context.

INT#010
Synopsis Use operator overloading sparingly and in a uniform manner
Level 9

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 20/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Category Class Interface

Status Unchecked
A disadvantage in overloading operators is that it is easy to misunderstand the meaning of an
overloaded operator (if natural semantics are not used). Do not use it if it can easily give rise to
misunderstanding. Keep to the old advice: "do as the int's do".

INT#011
If you overload one of a closely related set of operators, then you should overload
Synopsis
the whole set and preserve the same invariants that exist for built-in types
Level 9
Category Class Interface
Status Checked
When an expression is using one of the operators, it is expected to work with the opposite
operator as well.

INT#015
All variants of an overloaded member function shall be used for the same
Synopsis
purpose and have similar behavior
Level 2
Category Class Interface
Status Unchecked
Overloading of functions can be a powerful tool for creating a family of related functions that
only differ as to the type of data provided as arguments. If not used properly (such as using
functions with the same name for different purposes), they can, however, cause considerable
confusion.

INT#021
Pass arguments of class types by reference or pointer if the class is meant as a
Synopsis
public base class
Level 9
Category Class Interface
Status Checked
What is meant is that the function should be able to use the class interface of the passed object,
which may actually be of a derived type, in a polymorphic way. This is not possible if the object
is passed by value.

Note that such passing by value is not even possible if the argument refers to an abstract class.

INT#023

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 21/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

The copy constructor and the copy assignment operator shall always have a const
Synopsis
parameter
Level 5
Category Class Interface
Status Checked
The main reason for declaring the parameter const is to ensure that the original is not
accidentally "damaged" when making the copy. This is a good thing, because it is not expected
that the original object is changed when making a copy of it.

INT#026
In a derived class, if you need to override one of a set of the base class's
overloaded virtual member functions, then you must override the whole set, or
Synopsis
use using-declarations to bring all of the functions in the base class into the
scope of the derived class
Level 2
Category Class Interface
Status Checked
Rationale: The overload set can be hidded both by overRIDING or by overLOADING part of the
overload set in a derived class. Examples:

// OVERLOAD

// Incorrect
class Base
{
public:
void doSomething(char c);
};

class Derived : public Base

{
public:
void doSomething(int i);
}

int main()
{
char c = 'a';
int i = 100;
Derived d;

d.doSomething(i); // will call Derived::doSomething(int)

d.doSomething(c); // will unexpectedly call Derived::doSomething(int)
}

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 22/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

// Correct
class Base
{
public:
void doSomething(char c);
};

class Derived : public Base

{
public:
using Base::doSomething; // Exposes Base::doSomething(char)
void doSomething(int i);
};

int main()
{
char c = 'a';
int i = 100;
Derived d;

d.doSomething(i); // will call Derived::doSomething(int)

d.doSomething(c); // will call Base::doSomething(char)
}

// OVERRIDE

// INCORRECT
class Base
{
public:
virtual int doSomething(int i);
virtual double doSomething(double d);
};

class Derived : public Base

{
public:
int doSomething(int i) override;
};

int main()
{
int i = 2;
double dbl = 2.3;

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 23/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Derived d;

d.doSomething(i); // will call derived::doSomething(int)

d.doSomething(dbl) // will unexpectedly call derived::doSomething(int)
}

// CORRECT
class Base
{
public:
virtual int doSomething(int i);
virtual double doSomething(double d);
};

class Derived: public Base

{
public:
using Base::doSomething; // Exposes doSomething(double)
int doSomething(int i) override;
};

int main()
{
int i = 2;
double dbl = 2.3;
Derived d;

d.doSomething(i); // will call derived::doSomething(int)

d.doSomething(dbl) // will call derived::doSomething(double)
}

INT#027
If you override one of the base class's virtual functions, then you shall use the
Synopsis
"override" or "final" keyword
Level 2
Category Class Interface
Status Checked
It is not possible to remove the virtual-ness of an inherited virtual function: any virtual function
overrides itself. This rule makes explicit that the function that overrides a virtual function is
virtual too, which it would also have been if the overriding function were not declared as such.

By adding the "override" keyword you express your intention that this function is an override of
a function in the parent class. This is also checked by the compiler. If you make a mistake (see

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 24/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

example below) the compiler will issue an error to indicate that the function doesn't override
another function:

class base
{
public:
virtual int foo(float x) = 0;
};

class derived: public base

{
public:
virtual int foo(float x) { ... } // before C++11, not accepted any more
int foo(float x) override { ... } // C++11
}

class derived2: public base

{
public:
int foo(int x) override { ... } // won't compile!
};

INT#028
Supply default arguments with the function's declaration, not with the function's
Synopsis
definition
Level 2
Category Class Interface
Status Checked

INT#029
Synopsis Use built-in boolean type where possible
Level 6
Category Class Interface
Status Unchecked
For portability and readability reasons, use built-in boolean type where possible. All C++
standard conforming compilers support bool type.

INT#030
Synopsis Do not misuse a pointer when an array is requested
Level 2
Category Class Interface

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 25/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Status Checked
When a pointer is used as reference to an array, it shall refer to an array of the correct type.

Example:

void Foo( int a[], int size )

{
// do something with a;
for (int i = 0; i < size; i++)
{
a[i] = i;
}
}

int ar[] = {0,0,0};

Foo( ar, sizeof(ar)/sizeof(ar[0]) ); // Ok
...
int* ptr = &ar[1];
Foo( ptr, sizeof(ar)/sizeof(ar[0]) ); //Not allowed: passing pointer ptr in Foo causes
out of array bounds.

INT#031
Synopsis Don't use boost::noncopyable to make a class non-copyable
Level 5
Category Class Interface
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 26/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Classes and class hierarchies

C.21
If you define or =delete any copy, move, or destructor function, define or =delete
Synopsis
them all
Level 5
Category Classes and class hierarchies
Status Checked

C.127
Synopsis A class with a virtual function should have a virtual or protected destructor
Level 2
Category Classes and class hierarchies
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule C.127 for
more details.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 27/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Code Organization
ORG#001
Synopsis Enclose all code in header files within include guards
Level 3
Category Code Organization
Status Checked
This minimizes build time and prevents compilation problems due to redefinitions.

Alternative 1: include guards:

Adding the following preprocessor statements at the beginning of the header file prevents
multiple inclusion:

#ifndef FILENAME_H
#define FILENAME_H

And the following statement at the end:

#endif // FILENAME_H

See [Rule:STY#024] for the naming of these guards.

Alternative 2: #pragma once:

Although most modern compilers support this compiler directive, "#pragma once" is not an ISO
standard and thus not portable. It's nevertheless allowed to use "pragma once" because

it never leads to name clashes

it's less susceptible to typos

#pragma once

ORG#002
Synopsis Each file shall be self-contained
Level 3
Category Code Organization
Status Unchecked
This rule means that a file should be compilable in itself. For header files this is not enforced by
the compiler. So if the file is a header file, including this file in an empty source file should not
lead to compiler errors.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 28/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

ORG#003
Synopsis From a source file include only header files
Level 3
Category Code Organization
Status Checked
A source file only #includes header files. Source files are never #included.

ORG#004
Classes that are only accessed via pointers (*) or references (&) shall not be
Synopsis
included as header files
Level 8
Category Code Organization
Status Unchecked
When a class contains pointers or references to other classes, the header files of these
referenced classes need not be included in the header file defining the containing class. The
implementation file belonging to the containing class does of course need the header file with
the referenced classes. By doing so, code using the containing class does not depend on the
definition of the referenced classes. This limits dependencies and speeds up the building
process.

The here-described usage is explained with an example. Suppose that class CDemo, defined in
header file Demo.h, contains a pointer to Class CUsed and a reference to class COther defined in
files Used.h and Other.h. Then file Demo.h would look like:

Demo.h

class CUsed;
class COther;

class CDemo
{
public:
...

protected:
...

private:
CUsed* m_pUsed;
COther& m_rOther;
};

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 29/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Since the implementation file of class CDemo makes use of classes CUsed and COther, this file
does need to include the corresponding header files and thus the first part of this
implementation file looks like:

Demo.cpp

#include "......"
#include "Used.h"
#include "Other.h"
#include "Demo.h"
...

Note that this rule also holds for function results of class type.

ORG#005
Each file shall directly include each header file upon which declarations it directly
Synopsis
depends
Level 3
Category Code Organization
Status Unchecked
A file shall not depend on declarations that are only indirectly included by means of a nested
#include directive in some other included header file. Otherwise, it would be unnecessarily
difficult to change dependencies of a header file, even if it already was self-contained. It would
also be somewhat less obvious which files are the actual users of specific headers.

Exception:an exception to this is the inclusion of "stdafx.h" in Visual Studio. In this header file a
lot of files are combined to speed up the compilation process.

ORG#006
Synopsis C++ header files have the extension .h, .hpp or .hxx
Level 8
Category Code Organization
Status Checked
Using other extensions introduce complexity when used in the Visual C++ environment. For
ease of use the generally accepted extension .h, .hpp and .hxx are used.

ORG#007
Synopsis C++ source files have the extension .cpp
Level 8
Category Code Organization
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 30/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

C++ source files have the extension .cpp. This makes it easier to understand the meaning of files
in a software archive. Allowing other file extensions such as .tpl (templates) and .inl (inline files)
doesn't add sufficient value.

ORG#009
Synopsis Avoid unnecessary inclusion
Level 6
Category Code Organization
Status Unchecked
Do not include any header files that are not used by the including file.

Consider to use "compilation firewalls" such as abstract base classes and the so-called "pimpl"
programming idiom to reduce unnecessary compile-time coupling (see [Rule:ORG#004]).

Consider to use forward declarations of incomplete types. These declarations shall then be
localized in the "<basename>__fwd.h" header of a certain module. This not only prevents the
occurrence of such type declarations in headers with the wrong basename, but also makes such
dependencies much more explicit and traceable by means of an #include directive. Furthermore,
the localization of forward declarations in "__fwd.h" headers makes it possible to hide whether a
class name is a class template instantiation or not.

ORG#010
Synopsis Do not let assertions change the state of the program
Level 1
Category Code Organization
Status Checked
Assertions are used to verify assumptions made during development. For performance reasons it
should be possible to remove assert statements from the compiled code by means of
conditional compilation. Of course, when state changing statements are removed this way, the
program does not work anymore the way it was intended. For example:

// Wrong: allocation not done in release code

char *buf;
assert(buf = (char *) calloc( 20, sizeof(char)));
strcpy(buf, "Hello, World");
free(buf);

// Correct: allocation always done

char *buf;
buf = (char *) calloc( 20, sizeof(char));
assert(buf != nullptr);

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 31/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

strcpy(buf, "Hello, World");

free(buf);

ORG#011
Synopsis Everything must reside in a namespace
Level 7
Category Code Organization
Status Checked
A namespace is a declarative region that provides a scope to the identifiers (the names of types,
functions, variables, etc) inside it. Namespaces are used to organize code into logical groups and
to prevent name collisions that can occur especially when your code base includes multiple
libraries.

ORG#012
Synopsis Never put "using namespace" in header files
Level 5
Category Code Organization
Status Checked
Suppose you are using two libraries called Foo and Bar:

using namespace foo;

using namespace bar;

Everything works fine, you can call Blah() from Foo and Quux() from Bar without problems. But
one day you upgrade to a new version of Foo 2.0, which now offers a function called Quux().
Now you've got a conflict: Both Foo 2.0 and Bar import Quux() into your global namespace. This
is going to take some effort to fix, especially if the function parameters happen to match.

If you have used foo::Blah() and bar::Quux() then the introduction of foo::Quux() would have
been a non-event.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 32/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Comments
COM#002
Synopsis All files must include copyright information
Level 2
Category Comments
Status Checked
Each file should at least contain the word "Copyright" or "(c)", a reference to the name of the
company and a year.

COM#003
Synopsis All comments are to be written in English
Level 10
Category Comments
Status Checked
Fewer programmers may understand comments written in your native language (unless your
native language is English). Note that comments shall especially not contain any Greek or other
symbolic non-ASCII tokens, because they are not portable and cannot be handled properly by
the lexical analyzers of certain tools.

COM#005
Synopsis Do not leave commented-out code in the source file
Level 9
Category Comments
Status Checked
When commented-out code is left in the source file it may later be unclear if the code is still up-
to-date. It also may result in extra work when during maintenance the commented-out code is
kept up-to-date, even when the code may never be used again.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 33/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Control Flow
CFL#001
Statements following a case label shall be terminated by a statement that exits
Synopsis
the switch statement
Level 2
Category Control Flow
Status Checked
If the code which follows a case label is not terminated by break, the execution continues after
the next case label. A missing break statement can easily be overlooked resulting in erroneous
code. Usually a break will be used to exit the switch statement. Be careful when using a return to
exit the switch statement as in the example of ISC++: see [Rule:CFL#020].

Note that it is allowed to 'fall through' case labels: see [Rule:CFL#002].

CFL#002
Synopsis All switch statements shall have a default label as the last case label
Level 2
Category Control Flow
Status Checked
Example:

switch (c)
{
case c0: // fall-through
case c1:
{
x;
break;
}
case c2:
{
y;
break;
}
default: // always 'default' at end, even if no statement follows
{
z; // possibly an assertion that this should not be reached
break; // leave break: in case this becomes a non-default case
}
}

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 34/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

This rule doesn't hold for enumerations if all enum values are explicitly used as case labels in the
switch statement. If one of the enum values of the enumeration is missing in the switch body
this rule will trigger as well. This is to make sure one doesn't forget the add new enum values to
the switch statement in case the enumeration is extended.

enum Color { red, green, blue };

Color r = red;
switch (r)
{
case red : std::cout << "red\n"; break;
case green: std::cout << "green\n"; break;
case blue : std::cout << "blue\n"; break;
}

CFL#004
Synopsis Do not use goto
Level 7
Category Control Flow
Status Checked
The ISC++ rule is adapted to clarify that the goto statement is never allowed, as is explained in
ISC++. This implies that labels are only allowed in switch statements.

CFL#006
Synopsis Do not apply sizeof to an expression with side-effects
Level 1
Category Control Flow
Status Checked
The operand of sizeof is not evaluated, so any intended side-effects will not occur.

Example:

size_t Size = sizeof(nCount++); // Wrong: nCount not changed!

CFL#007
Synopsis Do not change a loop variable inside a for loop block
Level 2
Category Control Flow
Status Checked

CFL#009

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 35/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Never use continue in a nested loop

Level 9
Category Control Flow
Status Checked
The "continue" statement is used to force the next iteration of a loop to take place. This can help
to make loops in code more readable. Compare for instance the following code containing
"continue" statements:

for(object_id_t id : proc_list)
{
object* obj = find_object(id);
if(!obj)
continue;

if(obj->is_active())
continue;

time_t elapsed = now() - obj->begin;

if(elapsed < timeout)
continue;

...
}

with the semantically equivalent code without "continue" statements:

for(object_id_t id : proc_list)
{
object * obj = find_object(id);
if(obj)
{
if(!obj->is_active())
{
time_t elapsed = now() - obj->begin;
if(elapsed >= timeout)
{
...
}
}
}
}

The second example is less readable because nested "if" statements are needed.

But the "continue" statement also has a downside. Since "continue" is tied to its directly
enclosing loop, its meaning can change unexpectedly if the "continue" statement is moved. The

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 36/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

compiler will not warn you about this. Consider for example the following code:

for (int i = 0; i < max; i++) {

...
for (int j = 0; j < max; j++) {
...
some code
continue; // somewhere a little bit hidden
some other code
...
}
}

and suppose some lines of code are moved to the outer loop:

for (int i = 0; i < max; i++) {

...
some code
continue; // somewhere a little bit hidden
some other code
...
for (int j = 0; j < max; j++) {
...
}
}

Now all of a sudden the inner loop is not executed any more if the "continue" statement is
reached. If this is not intended it might take a lot of debugging effort to understand why this
happened. So it is better to avoid "continue" statements in nested loops.

CFL#011
Synopsis The test condition in control statements shall be a non-assignment expression
Level 9
Category Control Flow
Status Checked
The test condition shall not be an assignment expression. This avoids mistaking assignments for
comparisons.

Example:

bool b1 = true;
bool b2 = true;
int i = 123;

if (i != 0) // right: expression is a non-assignment

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 37/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

if (i = 123) // wrong: probably, (i == 123) was intended

if (b1 = (b1 && b2)) // wrong: even if this might seem convenient in some cases

CFL#014
Synopsis Do not return from unexpected locations
Level 9
Category Control Flow
Status Checked
It is harder to understand a function if, reading it at the bottom, you are unaware of the
possibility that it returned somewhere above. So multiple returns in a function should be
avoided, if possible. However, in some situations it is perfectly legal to have extra returns.
Examples are:

precondition checks that fail at the beginning of a function

loops that should terminate as soon as some condition is met (e.g. return the first element
larger than 10 in a list)

CFL#016
Synopsis Do not have overly complex functions
Level 4
Category Control Flow
Status Checked
If a function is too complex, it can be difficult to comprehend. The cyclomatic complexity of a
function, i.e. the number of linearly independent paths through a function, should not exceed
the agreed maximum. A function with a cyclomatic complexity less than 5 is considered to be ok.
However, if its cyclomatic complexity is higher than 10, refactoring is recommended.

CFL#017
Synopsis Do not make explicit comparisons to true or false
Level 9
Category Control Flow
Status Checked
It is usually bad style to compare a bool-type expression to true or false.

It is even dangerous to compare a non-bool-type expression to true: that might unexpectedly

evaluate to false.

Example:

while (condition == false) // wrong; bad style

while (condition == true) // wrong; possibly dangerous

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 38/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

while (boolean_condition) // okay if not an assignment, see CFL#011.

CFL#018
Synopsis Use range-based for loops if possible
Level 4
Category Control Flow
Status Checked
Most iterators and C-style index based for loops can be rewritten as range-based loops. Range-
based for loops are less error prone, so if possible, use them.

Wrong Example:

std::vector<char> myString;
for (auto iter = myString.begin(); iter != myString.end(); iter++)

Correct Example:

std::vector<char> myString;
for (auto & value : myString)

CFL#024
Synopsis A statement must have a side-effect, i.e., it must do something.
Level 1
Category Control Flow
Status Checked
Example:

i == 1; // WRONG - operator == has no effect

i; // WRONG - but legal!
i++; // RIGHT - does something

CFL#025
Synopsis Use a reference to a range based loop "auto" variable if it is modified in its body
Level 2
Category Control Flow
Status Checked
Consider the following code

std::vector<int> ints{ 10, 20, 30 };

for(auto i : ints) {

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 39/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

if (i == 30) {
i = 40;
}
}
do something with "ints"

Then after the for loop the "ints" variable will still be unchanged! Instead a reference to the
"auto" variable should be used:

std::vector<int> ints{ 10, 20, 30 };

for(auto& i : ints) {
if (i == 30) {
i = 40;
}
}
do something with "ints"

CFL#027
Synopsis Don't use complex conditions
Level 5
Category Control Flow
Status Checked

CP.42
Synopsis Don’t wait without a condition
Level 3
Category Control Flow
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule CP.42 for
more details.

ES.41
Synopsis If in doubt about operator precedence, parenthesize
Level 9
Category Control Flow
Status Checked

ES.43
Synopsis Avoid expressions with undefined order of evaluation
Level 1

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 40/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Category Control Flow

Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 41/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Conversions
CON#001
Synopsis Make unsafe type conversions explicit rather than implicit
Level 2
Category Conversions
Status Checked
If casting is required, make it explicit and use the following C++ cast operators:
const_cast: to remove the const, volatile, and __unaligned attributes.
dynamic_cast: for conversion of polymorphic types, where class hierachy navigation is
unavoidable.
static_cast: for conversion of nonpolymorphic types.
This rule does not only apply to casting: it also applies to unsafe conversions by means of
constructors, conversion operators, and conversion functions. See further [Rule:INT#001],
[Rule:INT#017], [Rule:POR#022].

CON#006
Synopsis Prefer static_cast over reinterpret_cast if possible
Level 4
Category Conversions
Status Unchecked
A static_cast is a cast from one type to another for which a known method for conversion is
available. For example, you can static_cast an int to a char because such a conversion is
meaningful. However, you cannot static_cast an int* to a double*, since this conversion only
makes sense if the int* has somehow been mangled to point at a double*.

A reinterpret_cast is a cast that represents an unsafe conversion that might reinterpret the bits
of one value as the bits of another value. For example, casting an int* to a double* is legal with a
reinterpret_cast, though the result is unspecified. Similarly, casting an int to a void* is perfectly
legal with reinterpret_cast, though it's unsafe.

Neither static_cast nor reinterpret_cast can remove const from something. You cannot cast a
const int* to an int* using either of these casts. For this, you would use a const_cast.

In general, you should always prefer static_cast for casts that should be safe. If you accidentally
try doing a cast that isn't well-defined, then the compiler will report an error. Only use
reinterpret_cast if what you're doing really is changing the interpretation of some bits in the
machine.

CON#007

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 42/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Do not convert implicitly from a boolean type to a non-boolean type, and vice
Synopsis
versa.
Level 3
Category Conversions
Status Checked
Example:

int i = 5, j = 4, k = 3, l = 2;

bool b = (i > j); // right

int a = (i > j); // wrong: implicit conversion from bool to int
int a = ((i > j) + (k > l)) // wrong: implicit conversion from bool to int

Exception:

Since smart pointers are designed according to the "safe bool idiom" (they behave correctly in
boolean context), it is also allowed to use a smart pointer in a boolean context, e.g.

shared_ptr<A> a_sp = someFunctionReturningSharedPtr();

bool my_bool = a_sp; // right: smart pointers are implicitly of boolean type

CON#009
Synopsis Don't compare an address to null
Level 2
Category Conversions
Status Checked
Comparing an address to null will always be false. So if this happens it is probably not intended.
For example:

#include <stdio.h>

class Foo {};

void var(Foo* foo)

{
if (&foo == nullptr) return;
printf("YES\n");
}

will always print "YES". Probably

if (foo == nullptr) return;

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 43/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

was meant.

CON#010
Synopsis Avoid unnecessary casts
Level 5
Category Conversions
Status Checked

ES.49
Synopsis If you must use a cast, use a named cast
Level 1
Category Conversions
Status Checked

ES.50
Synopsis Don't cast away const
Level 2
Category Conversions
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 44/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Error Handling
ERR#001
Synopsis Do not let destructors throw exceptions
Level 1
Category Error Handling
Status Checked
In contrast to what is said in ISC++, do not rely on the std::uncaught_exception function. That
function is not always properly implemented by mainstream compilers. Furthermore, there are
certain situations where this function is actually useless for the purpose it is intended for!

Any destructor can be called as a result of stack-unwinding due to an exception. If that

destructor would throw another exception by itself, then the program will terminate without
further cleanup handling. That is almost never a desirable situation. Therefor, destructors shall
never throw an exception.

Note that a function called by a destructor is allowed to throw an exception! As long as you
make sure that the destructor handles any exception if that might be thrown by its
implementation.

ERR#003
Before letting any exceptions propagate out of a member function, make certain
Synopsis that the class invariant holds and, if possible, leave the state of the object
unchanged
Level 1
Category Error Handling
Status Unchecked
This avoids that the object throwing an exception is left in an inconsistent (undefined) state. For
more details see [Literature:Abrahams].

ERR#005
Synopsis Check for all errors reported from functions
Level 6
Category Error Handling
Status Checked
If an error reported this way is ignored, there is no easy way of knowing what eventually made
the program crash. It seems natural to check status values returned from functions, but in reality
there are huge amounts of code written that does not do these checks. The fact that status

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 45/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

values can be ignored by the programmer is one of the reasons to why exception handling in
most cases is a better way of reporting errors.

Example:

// create socket
int socketfd = socket(AF_UNIX, SOCK_STREAM, 0);
if (socketfd < 0) // check status value
{
// ...
}

Using (void) to cast-away the return value is allowed.

(void) FunctionWithReturnValue();

ERR#006
Synopsis Don't use exception specifications, but do use noexcept when applicable
Level 1
Category Error Handling
Status Checked
Exception specifications are a way to state what kind of exceptions are thrown by a function, e.g.

int Gunc() throw(); // will throw nothing

int Hunc() throw(A,B); // can only throw A or B

There are a couple of disadvantages with this approach:

Exception specifications are not checked compile-time. If a function appears to throw

another exception as specified in the exception specification then a run-time error will occur
that can't be caught.
Exception specifications are only allowed for plain functions. It won't work for typedefs for
instance.
Exception specifications result in run-time overhead, thus affecting performance

This is the reason why exception specifications have been deprecated in C++11. The keyword
"noexcept(boolean)" has been introduced instead to indicate that a function might throw or
won't throw an exception, depending on the value of the boolean, e.g.

int Gunc() noexcept(true); // will throw nothing

int Gunc() noexcept; // same as previous one
int Hunc() noexcept(false); // may throw an exception

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 46/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Note that this standard doesn't enforce the use of "noexcept", it only deprecates the use of
exception specifications.

ERR#012
Synopsis Throw only objects of class type
Level 1
Category Error Handling
Status Checked
Exceptions pass information up the call stack to a point where error handling can be performed.
Class types can have member data with information about the cause of the error, and also the
class type itself is further documentation of the cause. User exception types should derive from
std::exception or one of its derived classes.

Wrong examples:

void m(int x) {
throw 23; // wrong
throw x; // wrong

try {}
catch (int y) {
throw; // wrong
throw y; // wrong
}

Correct examples:

void m(int x) {
try {}
catch (Exception& e) {
throw; // right
throw e; // right
}
}

ERR#014
Synopsis Do not catch objects by value
Level 1
Category Error Handling
Status Checked
If objects are caught by value, there is a risk the exception will be sliced. See for instance the
following example:

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 47/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

class Exception{};
class SpecialException : public Exception {};

try {
throw SpecialException();
} catch (Exception e) {
cout << "Caught" << typeid(e).name() << endl;
}

A SpecialException is thrown but its parent Exception is caught. We are catching by value, which
results in copying the exception. But since we are catching Exception, not SpecialException,
Exception’s copy construcor is called, and we lose the SpecialException part of the object.

The right way to write this would be to use a const reference:

class Exception{};
class SpecialException : public Exception {};

try {
throw SpecialException();
} catch (const Exception& e) {
cout << "Caught" << typeid(e).name() << endl;
}

This will result in a reference to the original SpecialException.

ERR#015
Synopsis Always catch exceptions the caller is not supposed to know about
Level 9
Category Error Handling
Status Unchecked
Hidden implementation details is an important property of well written programs, since it gives
you the possibility to make changes without affecting the user.

Imagine a hierarchy of libraries where some libraries are implemented on top of other libraries.
To be able to change or replace lower level classes without affecting the user, you must catch all
exceptions that the user is not supposed to know about. Otherwise an exception of a class
unknown to the user could terminate the program or be caught by a handler with a ... parameter
list. In either case, nothing can be said about what caused the exception to be thrown. All
exceptions that reach the user should be known to the user, since that will make it possible to
explain why the exception was thrown and how to prevent it from being thrown. You should try
to avoid writing programs that simply crash without any proper indication of what went wrong.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 48/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

ERR#016
Synopsis Do not catch exceptions you are not supposed to know about
Level 9
Category Error Handling
Status Unchecked
Catch an exception only when you actually can do something about the problem that caused it
or at least leave the application in a consistent state. Else throw it along and let someone up the
call stack handle it.

ERR#017
Synopsis A catch-all clause must do a rethrow
Level 3
Category Error Handling
Status Checked
If a catch clause catches all possible exceptions without rethrowing, all exceptions are lost.
void f()
{
try
{
// Do something
}
catch (...) // catch any exception
{
// Cleanup

throw; // Always rethrow the exception if catched all

}
}

Only the "main" function of a thread must catch and report all exceptions without rethrowing.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 49/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Functions
F.5
Synopsis If a function is very small and time-critical, declare it inline
Level 5
Category Functions
Status Checked

F.50
Use a lambda when a function won't do (to capture local variables, or to write a
Synopsis
local function)
Level 9
Category Functions
Status Checked

F.53
Avoid capturing by reference in lambdas that will be used non-locally, including
Synopsis
returned, stored on the heap, or passed to another thread
Level 8
Category Functions
Status Checked

F.54
When writing a lambda that captures this or any class data member, don't use [=]
Synopsis
default capture
Level 5
Category Functions
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 50/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

General
GEN#002
Synopsis Company C++ code shall be clearly separated from 3rd party code
Level 9
Category General
Status Unchecked
Maintain a clear separation between in-house developed code and 3rd party source files, which
includes generated code. Note that this may require explicit attention in the design phase. In
general, interfaces and interoperability with 3rd party code shall be clearly documented in the
design.

It is allowed to use interfaces defined by header files of 3rd party libraries directly in company
C++ code. An example is the use of standard C++ libraries. It is not obligatory to hide such an
interface by means of a company specific C++ wrapper, although there may be good reasons,
such as improved portability, to do so in specific cases.

If possible, C++ code that is maintained by the company, should not be located 'embedded' in
generated 3rd party code. In any case, files containing such mixed code should be clearly
separated from regular company C++ files. Such mixed files will almost certainly contain several
coding standard violations, and the relevant design document shall, identify the violated rules
and specify alternative rules that do apply. The documentation should also specify which design
patterns are used to separate and localize the parts of the implementation that are partly
generated and therefore contains coding standard violations.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 51/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Naming
NAM#002
Synopsis Do not use identifiers which begin with an underscore ('_') followed by a capital
Level 1
Category Naming
Status Checked
Identifier names which begin with an underscore followed by a capital are reserved for compiler
specific identifiers.

NAM#008
Synopsis Do not use identifiers that contain two or more underscores in a row
Level 1
Category Naming
Status Checked
Identifier names which contain two or more underscores in a row are reserved for compiler
specific identifiers.

Exception: extern variables are excluded from this rule.

NAM#016
Synopsis Classes and namespaces should not have identical names
Level 3
Category Naming
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 52/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Object Allocation
OAL#002
Synopsis If you overload operator delete, it shall be prepared to accept a null pointer
Level 1
Category Object Allocation
Status Unchecked
Passing a null pointer to operator delete shall always be allowed, and have no effect. This also
applies to operator delete[].

OAL#004
In case allocated memory has to be deallocated later by someone else, use a
Synopsis
unique_ptr with move semantics
Level 1
Category Object Allocation
Status Unchecked
Example:

std::unique_ptr<Foo> createFoo() {
std::unique_ptr<Foo> ptr(new Foo);
// return unique pointer to Foo
return ptr;
}

void m() {
auto foo = createFoo();
// transfer ownership of foo to bar
Bar bar(std::move(foo));
}

OAL#009
Synopsis Do not overload the global operator new or the global operator delete
Level 2
Category Object Allocation
Status Checked
Other users may depend on the default behavior of these operators. See section 15.6 in ref.
[ref:Stroustrup]. If necessary, overload these operators for a specific class. See also Rec.
[rule:OAL#003].

OAL#012
https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 53/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Don't use auto_ptr, use unique_ptr instead

Level 2
Category Object Allocation
Status Checked
auto_ptr is deprecated as of C++11. Instead, unique_ptr should be used. It has similar
functionality, but improved security (no fake copy assignments), added features (deleters) and
support for arrays.

OAL#013
Synopsis Use std::make_shared instead of constructing a shared_ptr from a raw pointer
Level 2
Category Object Allocation
Status Checked
There are a couple of advantages to prefer std::make_shared to the ordinary way of creating a
shared pointer.

Better readibility (see example below)

Less memory consumption
Better exception-safety

Example (wrong):

std::shared_ptr<Object> ptr(new Object("foo"));

Example (correct):

std::shared_ptr<Object> ptr = std::make_shared<Object>("foo");

Example (correct, even better):

auto ptr = std::make_shared<Object>("foo");

OAL#018
Synopsis Don't forget to give scoped variables a name
Level 1
Category Object Allocation
Status Checked
If you don't give scoped variables a name, the corresponding anonymous object will be created
and destroyed immediately, but not at the end of its scope (as it would be expected). This is
extremely dangerous in RAII (Resource Allocation Is Initialization) patterns or SBRM (Scope-

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 54/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Bound Resource Management) patterns, where resource allocation and cleanup depends on
object life time, e.g. when allocating heap memory, sockets, files, locks, etc.

Take a look at the following code:

void EventListenerHelper::ClearEvents()
{
boost::mutex::scoped_lock(m_mutex);
m_events.clear();
}

The field "m_mutex" is locked and released immediately after that, so that the clear() operation
is actually not locked as expected.

It should have been something like

void EventListenerHelper::ClearEvents()
{
boost::mutex::scoped_lock my_lock(m_mutex);
m_events.clear();
}

instead. The scoped lock is now named "my_lock" and will remain alive until the end of the
function scope.

OAL#019
Synopsis Don't use the default constructor when creating a local unique_lock
Level 1
Category Object Allocation
Status Checked

R.3
Synopsis A raw pointer (a T*) is non-owning
Level 5
Category Object Allocation
Status Checked

R.5
Synopsis Prefer scoped objects, don't heap-allocate unnecessarily
Level 5
Category Object Allocation

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 55/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Status Checked

R.11
Synopsis Avoid calling new and delete explicitly
Level 2
Category Object Allocation
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule R.11 for
more details.

R.13
Synopsis Perform at most one explicit resource allocation in a single expression statement
Level 5
Category Object Allocation
Status Unchecked

R.15
Synopsis Always overload matched allocation/deallocation pairs
Level 1
Category Object Allocation
Status Checked

R.20
Synopsis Use unique_ptr or shared_ptr to represent ownership
Level 5
Category Object Allocation
Status Checked

R.21
Synopsis Prefer unique_ptr over shared_ptr unless you need to share ownership
Level 5
Category Object Allocation
Status Checked

R.22
Synopsis Use make_shared() to make shared_ptrs
Level 5

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 56/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Category Object Allocation

Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule R.22 for
more details.

R.30
Synopsis Take smart pointers as parameters only to explicitly express lifetime semantics
Level 5
Category Object Allocation
Status Checked

R.33
Take a unique_ptr<widget>& parameter to express that a function reseats the
Synopsis
widget
Level 5
Category Object Allocation
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 57/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Object Life Cycle

ES.5
Synopsis Keep scopes small
Level 9
Category Object Life Cycle
Status Checked

ES.10
Synopsis Declare one name (only) per declaration
Level 9
Category Object Life Cycle
Status Checked

ES.12
Synopsis Do not reuse names in nested scopes
Level 2
Category Object Life Cycle
Status Checked

ES.20
Synopsis Always initialize an object
Level 1
Category Object Life Cycle
Status Checked

I.2
Synopsis Avoid non-const global variables
Level 4
Category Object Life Cycle
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule I.2 for more
details.

OLC#001
If objects of a class should never be copied, then the copy constructor and the
Synopsis
copy assignment operator shall be declared as deleted functions

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 58/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Level 2
Category Object Life Cycle
Status Checked
Use deleted functions instead of old-fashioned private declarations to prohibit copying.

Wrong example:

class SomeClass {
private:
SomeClass(SomeClass const&);
SomeClass& operator=(SomeClass const&);
};

Right example:

class SomeClass {
public:
SomeClass(SomeClass const&) = delete;
SomeClass& operator=(SomeClass const&) = delete;
};

OLC#003
A function must never return, or in any other way give access to, references or
Synopsis
pointers to local variables outside the scope in which they are declared
Level 2
Category Object Life Cycle
Status Checked
If a function returns a reference or a pointer to a local variable, the memory to which it refers will
already have been deallocated, when this reference or pointer is used. Note that the scope in
this rule refers to the lifetime-scope. It is never allowed that a function gives access to a local
automatic stack variable. However, if the lifetime of a local variable exceeds the lifetime of its
block, then it may well be appropriate to give access to it from other scopes. This might be the
case for static or new allocated objects.

OLC#004
Every variable of a built-in type that is declared is to be given a value before it is
Synopsis
used
Level 1
Category Object Life Cycle
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 59/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

This value can be assigned in the declaration or later on, as long as a variable is assigned a value
before it is used.

Some examples:

int number = 10;

if (func(number)) ...

or

int number;
...
number = 10;
if (func(number)) ...

This rule can be checked by most modern compilers.

OLC#005
Synopsis Don't call virtual functions in constructors and destructors
Level 1
Category Object Life Cycle
Status Checked
Reason The function called will be that of the object constructed so far, rather than a possibly
overriding function in a derived class. This can be most confusing. Worse, a direct or indirect call
to an unimplemented pure virtual function from a constructor or destructor results in undefined
behavior.

Example, bad

class Base {
public:
virtual void f() = 0; // not implemented
virtual void g(); // implemented with Base version
virtual void h(); // implemented with Base version
virtual ~Base(); // implemented with Base version
};

class Derived : public Base {

public:
void g() override; // provide Derived implementation
void h() final; // provide Derived implementation

Derived()

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 60/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

{
// BAD: attempt to call an unimplemented virtual function
f();

// BAD: will call Derived::g, not dispatch further virtually

g();

// GOOD: explicitly state intent to call only the visible version

Derived::g();

// ok, no qualification needed, h is final

h();
}
};

Note that calling a specific explicitly qualified function is not a virtual call even if the function is
virtual.

Note There is nothing inherently wrong with calling virtual functions from constructors and
destructors. The semantics of such calls is type safe. However, experience shows that such calls
are rarely needed, easily confuse maintainers, and become a source of errors when used by
novices.

OLC#009
Synopsis Literals should be used only on the definition of constants and enumerations
Level 7
Category Object Life Cycle
Status Checked
Avoiding literal values usually enhances maintainability and readability. Uncommon literal
numeric values are called "magic numbers". Having 2 or more identical magic numbers in the
same scope is dangerous. If one needs to change the magic number there is a risk that one
forgets to change the others.

Wrong example:

if (mode == 23) {
throw MyException(23);
}

Correct example:

const int IncorrectState = 23;

if (mode == IncorrectState) {

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 61/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

throw MyException(IncorrectState);
}

Note that the following numbers are considered to be no magic numbers: 0, powers of 2,
powers of 10 and the well known angles: 90, 180, 270 and 360. Another exception concerns
const array definitions.

OLC#012
Synopsis Do not initialise static variables with other (external) static variables
Level 6
Category Object Life Cycle
Status Checked
The standard states that static variables are zero initialised before their first use. The order of
initialization is not defined across compilation units. So when a static variable is being initialized
with another (external) static variable it might be initialised with only the zero initialised value
instead of the programmer intended initialised value.

Violating example:

extern int i;

class A
{
public:
// error: i might be initialised with 0 or the intended value
static int j = i;
};

Non-violating example:

int i = 5;

class A
{
public:
static int j = i;
};

OLC#018

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 62/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Let the order of the initializer list be: first base class constructor(s), then data
Synopsis
members in the same order of declaration as in the header file
Level 1
Category Object Life Cycle
Status Checked
The order in the initializer list is irrelevant to the execution order of the initializers. Putting
initializers for data members and base classes in any other order than their actual initialization
order is therefore highly confusing and error-prone. A data member could be accessed before it
is initialized if the order in the initializer list is incorrect, see Example1.

Virtual base classes are always initialized first. Then base classes, data members and finally the
constructor body for the most derived class is run, see Example2.

Example1:

class Foo
{
public:
Foo(int a, int b) : A(a), B(b), C(A * B) { } // C is initialized before B
which at that moment still undefined!

private:
int A;
int C; //C initialization depends on A and B and therefore should be
declared after A and B.
int B;
};

Example2:

class Derived : public Base // Base is number 1

{
public:
explicit Derived(int i);
Derived();
private:
int jM; // jM is number 2
Base bM; // bM is number 3
};

Derived::Derived(int i) : Base(i), jM(i), bM(i)

// Recommended order 1 2 3
{
// Empty
}

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 63/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

OLC#019
If passing the "this" pointer to a constructor initializer list, be aware that the
Synopsis
object is not yet fully constructed
Level 5
Category Object Life Cycle
Status Checked
The "this" pointer can be used in the constructors list of initializers for base classes and member
variables. While doing so is valid, you must ensure that those base classes and member variables
do not use the passed in "this" pointer to access parts of this object until those parts have been
initialized sufficiently. In particular, any virtual functions should not be called until the rest of the
initializer list and the most necessary parts of the constructor code have been executed, nor
should any members of *this be accessed until those particular members have been initialized.

Example (wrong):

class CC;

class B {
int &r_x1;
public:
B(CC *c);
};

class CC {
public:
B b;
int &r_x2;
CC(int &i): r_x2(i), b(this) {} // Violation!
};

B::B(CC *c): r_x1( c->r_x2 ) {

}

This will crash because b is initialized before r_x2, because the B constructor assumes that r_x2
can be safely duplicated into r_x1, neither of which is true until after r_x2 is initialized.

Example (right):

class A {
int m_x;
class A_xWrap {
A& parent;
public:
A_xWrap(A* pParent): parent(*pParent) {}

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 64/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

A_xWrap & operator = (int x) { parent.x_Put(x); return *this; }

int operator int (void) const { return parent.x_Get(); }
}
public:
A_xWrap x;
A() : x(this), m_x(2) { } // OK
int x_Get(void) { return m_x; }
void x_Put(int i) { if (i>= 0) x = i; }
};

This is safe because A_xWrap does not access this until something after this constructor returns
tries to use the x field as if it was the m_x field.

OLC#020
Synopsis Don't pass member variables to the base class in the constructor's initializer list
Level 2
Category Object Life Cycle
Status Checked
Because the base class is created before the member variables, these members are not
created/initialized yet in the constructor of the base class. If the constructor of the base class
uses one of the parameters, an access violation error is inevitable when this constructor is called.

Example:

class Base
{
public:
Base(DMember& m)
{
m.Test(); // Access violation!!!
}
};

class Derived: public Base

{
public:
Derived()
: Base(m_Member)
{
}
private:
DMember m_Member; // Class DMember contains a Test method which uses DMember
data
}

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 65/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

If an object of Derived is created, then first Base is created with the not-constructed m_Member
as input argument. When the Base constructor calls the Test method, an access violation
exception will occur.

OLC#021
Synopsis Initialize atomic variables correctly
Level 1
Category Object Life Cycle
Status Checked
If an atomic variable is not default constructed, its behavior will be undefined. So it is important
to make sure that atomic variables are initialized in the class definition or via the initializer list of
the constructor. For example:

class C
{
public:
C(int x);
private:
std::atomic<int> i { 0 };
};

or alternatively

C::C(int x)
: i(x)
{}

Never use atomic_init, because if it is already initialized its behavior is undefined:

C::C(int x)
{
… Some calculation …
std::atomic_init(&i, y);
}

OLC#022
Don't call functions expecting a reference to a std::string with a null pointer
Synopsis
argument
Level 1
Category Object Life Cycle
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 66/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

OLC#023
Synopsis Objects should be constructed in a uniform way
Level 3
Category Object Life Cycle
Status Checked

R.2
Synopsis In interfaces, use raw pointers to denote individual objects (only)
Level 6
Category Object Life Cycle
Status Checked

R.23
Synopsis Use make_unique() to make unique_ptrs
Level 5
Category Object Life Cycle
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule R.23 for
more details.

R.34
Synopsis Take a shared_ptr<widget> parameter to express shared ownership
Level 5
Category Object Life Cycle
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule R.34 for
more details.

R.35
Take a shared_ptr<widget>& parameter to express that a function might reseat
Synopsis
the shared pointer
Level 5
Category Object Life Cycle
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule R.35 for
more details.

R.37
https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 67/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Do not pass a pointer or reference obtained from an aliased smart pointer
Level 5
Category Object Life Cycle
Status Checked
This is a rule of the C++ core guidelines, see the C++ core guidelines page for rule R.37 for
more details.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 68/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Object Oriented Programming

OOP#002
A public method must never return a non-const reference or pointer to member
Synopsis
data
Level 2
Category Object Oriented Programming
Status Unchecked
This prevents the calling method from being able to manipulate the data member.

Example:

class Account
{
public:
Account( int myMoney ) : moneyAmount( myMoney ) {};
const int& getSafeMoney() const { return moneyAmount; }
int& getRiskyMoney() const { return moneyAmount; } // No!
// ...
private:
int moneyAmount;
};

Account myAcc(10); // I'm a poor lonesome programmer a long way from home

myAcc.getSafeMoney() += 1000000; // Compilation error: assignment to constant

myAcc.getRiskyMoney() += 1000000; // myAcc::moneyAmount = 1000010 !!

Singleton patterns are an exception to this rule. Well-known examples of other exceptions to
this rule are container classes (e.g. std::vector), operator<<, operator= and various Qt methods.

OOP#003
A public method must never return a non-const reference or pointer to data
Synopsis
outside an object, unless the object shares the data with other objects
Level 2
Category Object Oriented Programming
Status Unchecked
Although, the data exists outside the object it is still part of the state of the object. The calling
method should not be able to manipulate this data.

OOP#004
https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 69/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Derive from more than one base class with the same parent with care
Level 9
Category Object Oriented Programming
Status Checked
This rule prevents potential problems caused by multiple derived classes of a common base
class. The example below shows why this is problematic:

class Base {
public:
// ...
protected:
int data_;
};
class Der1 : public Base { /*...*/ };
class Der2 : public Base { /*...*/ };
class Join : public Der1, public Der2 {
public:
void method()
{
data_ = 1; // Bad: this is ambiguous; see below
}
};
int main()
{
Join* j = new Join();
Base* b = j; // Bad: this is ambiguous; see below
}

The key is to realize that Base is inherited twice, which means any data members declared in
Base, such as data_ above, will appear twice within a Join object. This can create ambiguities:
which data_ did you want to change? For the same reason the conversion from Join* to Base*, or
from Join& to Base&, is ambiguous: which Base class subobject did you want? One way to avoid
this problem is using virtual inheritance. This comes down to derive virtually from the Base class:

class Base {
public:
// ...
protected:
int data_;
};
class Der1 : public virtual Base {
public:
// ...
};
class Der2 : public virtual Base {

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 70/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

public:
// ...
};
class Join : public Der1, public Der2 {
public:
void method()
{
data_ = 1; // Good: this is now unambiguous
}
};
int main()
{
Join* j = new Join();
Base* b = j; // Good: this is now unambiguous
}

Another way to avoid these common base class problems is to make sure the base class doesn't
contain members, is virtual and has a default constructor.

OOP#007
Selection statements (if-else and switch) should be used when the control flow
Synopsis depends on an object's value; dynamic binding should be used when the control
flow depends on the object's type
Level 9
Category Object Oriented Programming
Status Unchecked
Heavy use of the selection statements if / else and switch might be an indication of a poor
design. Selection statements should mostly be used when the flow of control depends on the
value of an object.

Selection statements are not the best choice if the flow of control depends on the type of an
object. If you want to have an extensible set of types that you operate upon, code that uses
objects of different types will be difficult and costly to maintain. Each time you need to add a
new type, each selection statement must be updated with a new branch. It is best to localize
selection statements to a few places in the code. This however requires that you use inheritance
and virtual member functions.

Suppose you have a class that is a public base class. It is possible to operate on objects of
derived classes without knowing their type if you only call virtual member functions. Such
member function calls are dynamically bound, i.e. the function to call is chosen at run-time.
Dynamic binding is an essential component of object-oriented programming and we cannot
overemphasize the importance that you understand this part of C++. You should try to use
dynamic binding instead of selection statements as much as possible. It gives you a more

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 71/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

flexible design since you can add classes without rewriting code that only depends on the base
class interface.

OOP#009
Synopsis Avoid inheritance for parts-of relations
Level 9
Category Object Oriented Programming
Status Unchecked
A common mistake is to use multiple inheritance for parts-of relations (when an object consists
of several other objects, these are inherited instead of using instance variables). This can result in
strange class hierarchies and less flexible code. In C++ there may be an arbitrary number of
instances of a given type; if inheritance is used, direct inheritance from a class may only be used
once.

OOP#011
Synopsis Never redefine an inherited non-virtual method
Level 2
Category Object Oriented Programming
Status Checked
In the following code a non-virtual method is redefined, which is not allowed.

class Base
{
public: // Methods
void Foo();
};

class Derived : public Base

{
public: // Methods
void Foo(); // Not allowed !!!
};

The reasons can be found in "Effective C++" item 37 (see [Literature:Meyers]). When an inherited
non-virtual method may not be redefined, it may also not be made virtual in the derived class,
as in:

class Base
{
public: // Methods
void Foo();
};

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 72/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

class Derived : public Base

{
public: // Methods
virtual void Foo(); // Not allowed !!!
};

Exception: this rule doesn't hold for classes that have been derived privately from its base class
because in such a case no harm can be done.

OOP#017
It shall be possible to use a pointer or reference to an object of a derived class
Synopsis
wherever a pointer or reference to a public base class object is used
Level 3
Category Object Oriented Programming
Status Unchecked
A class inherits from another class to reuse either the implementation or the class interface.
Public inheritance makes it possible to write code that only depends on the base class interface,
not the implementation. Public inheritance should only be used if derived class objects are
supposed to be operated upon through base class pointers or references.

This rule is known as the "Liskov Substitution Principle", see [Literature:Liskov] for more details.

OOP#018
When overriding a (virtual) function from a base class, the derived class should
Synopsis
give the same const modifier to the function.
Level 2
Category Object Oriented Programming
Status Checked
This prevents unintentionally calling the function of the base class.

class Base
{
public: // Methods
virtual void f() const;
};

class Derived : public Base

{
public: // Methods
virtual void f(); //This is not an override, not allowed !!!
};

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 73/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

The reason is when a client attempts a polymorphic call to f() through a const pointer or const
reference to Base, it will call Base::f() and not Derived::f(), which is syntactically correct but
probably surprising. The same care should be used when overriding a function with a parameter
that is a pointer or reference to const.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 74/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Optimization and Performance

OPT#001
Synopsis Avoid duplicated code and data
Level 4
Category Optimization and Performance
Status Unchecked
When duplicating code and data makes the program unnecessary large, which can effect the
overall performance of the system. More time will be spent in swapping programs in and out of
memory. Furthermore, the code becomes harder to maintain, because when the code or data
has to be changed, it has to be done at multiple source locations.

OPT#002
Optimize code only if you know that you have a performance problem. Think
Synopsis
twice before you begin
Level 7
Category Optimization and Performance
Status Unchecked
A lot of time may be lost optimizing code without significant performance improvement. If you
have a performance problem, use a performance-analyzing tool, to determine where a
bottleneck exists.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 75/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Parts of C++ to Avoid

PCA#001
Synopsis Don't use malloc, calloc, realloc, free and cfree for memory management
Level 1
Category Parts of C++ to Avoid
Status Checked
In C malloc, realloc and free are used to allocate memory explicitly on the heap. In C++ one
should use automated memory management by means of smart pointers instead.

PCA#002
Synopsis Do not assume that an enumerator has a specific value
Level 4
Category Parts of C++ to Avoid
Status Checked
A common pitfall is that it is assumed that the enumerators of an enumeration run from 0 to
(max - 1). Although each enumerator has an integer value, no code may be written that relies on
the integer value of the enumerator.

Incorrect example:

enum Color { red, green, blue };

Color color = 2;

Correct example:

enum Color { red, green, blue };

Color color = green;

Another mistake is to rely on the order of the enum elements. The order might change over
time.

Incorrect example:

enum Color { red, green, blue };

if (color >= green) { ... }

Correct example:

enum Color { red, green, blue };

if (color == green || color == blue) { ... }

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 76/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Important note. Instead of using old style enums, it is better to use enum classes. See also
[Rule:PCA#016]. Enum classes don't allow conversions between enum values and integers. The
compiler will issue a compiler error for this.

PCA#003
Use overloaded functions and chained function calls instead of functions with an
Synopsis
unspecified number of arguments
Level 4
Category Parts of C++ to Avoid
Status Checked
Functions or methods using variable arguments should not be used unless very good reasons
exist to do so. This is not advised since the strong type checking provided by C++ is thereby
avoided. The intended effect can often be reached using function overloading.

PCA#005
Synopsis Use the iostream library instead of C-style I/O
Level 9
Category Parts of C++ to Avoid
Status Checked
The iostream library is more type-safe, efficient, and extensible than stdio. See also
[Rule:GEN#001].

PCA#006
Synopsis Do not use setjmp and longjmp
Level 1
Category Parts of C++ to Avoid
Status Checked

PCA#008
Synopsis Do not redefine keywords
Level 1
Category Parts of C++ to Avoid
Status Checked
Do not use the preprocessor to redefine C++ keywords. Abominations such as #define private
public are most certainly forbidden, but also the VC++ generated code #define new
DEBUG_NEW must be removed.

PCA#009

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 77/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Use an array class instead of built-in arrays

Level 9
Category Parts of C++ to Avoid
Status Checked
Especially the std::vector class template is usually a better alternative than built-in arrays for
several reasons:

They allocate memory from the free space when increasing in size.
They are NOT a pointer in disguise.
They can increase/decrease in size run-time.
They can do range checking using at().
A vector knows its size, so you don't have to count elements.

The most compelling reason to use a vector is that it frees you from explicit memory
management, and it does not leak memory. A vector keeps track of the memory it uses to store
its elements. When a vector needs more memory for elements, it allocates more; when a vector
goes out of scope, it frees that memory. Therefore, the user needs not be concerned with the
allocation and deallocation of memory for vector elements.

An exception to this rule are built-in arrays that are used in a local scope.

PCA#010
Synopsis Do not use unions
Level 6
Category Parts of C++ to Avoid
Status Checked
One way to simulate unions is using variants. Variants are type-safe unions. They are available
since C++17. An instance of std::variant at any given time either holds a value of one of its
alternative types, or in the case of error - no value. The latter state is hard to achieve.

Example (wrong):

union SuperFloat
{
float f;
int i;
};

Example (right):

using std::variant

See the reference to StackOverflow for a discussion when to use variants over unions.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 78/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

PCA#011
Synopsis Do not use bit-fields
Level 5
Category Parts of C++ to Avoid
Status Checked
If breaking this rule is necessary, one must be very well aware of the undefined properties of bit-
fields, and provide adequate documentation. In general, prevent to rely on the exact memory
layout of objects: see also [Rule:POR#020]. When the purpose is to manipulate a set of a number
of bits, then the std::bitset class template is a better alternative.

PCA#016
Synopsis Use enum classes instead of old-style enums
Level 7
Category Parts of C++ to Avoid
Status Checked
Old-style C++ enums are essentially integers; they could be compared with integers or with
other enums of different types without getting compilation errors. Most of the times this is not
intentional. Now with strongly typed enums, the compiler will not accept this any more. If really
needed, you can always use a typecast.

Another limitation of old-style enum values is that they are unscoped--in other words, you
couldn't have two enumerations that shared the same name:

// this code won't compile because both enums contain BLUE!

enum Color {RED, GREEN, BLUE};
enum Feelings {EXCITED, MOODY, BLUE};

This in contrast with enum classes:

// this code will compile (if your compiler supports C++11 strongly typed enums)
enum class Color {RED, GREEN, BLUE};
enum class Feelings {EXCITED, MOODY, BLUE};

The use of the word class is meant to indicate that each enum type really is different and not
comparable to other enum types. Strongly typed enums, enum classes, also have better scoping.
Each enum value is scoped within the name of the enum class. In other words, to access the
enum values, you must write:

Color color = Color::GREEN;

if ( Color::RED == color )
{

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 79/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

// the color is red

}

Yet another advantage of enum classes is that it is possible to specify the underlying type (that
is: the byte size), which is very useful when using this enum declaration in definition of network
protocols or other binary data. Otherwise the size of the enum is compiler dependent (usually
machine word size), which is not portable. Example:

enum class Permissions : unsigned short {Readable = 0x4, Writable = 0x2, Executable =
0x1};

PCA#017
Synopsis Don't compare unrelated enumerations
Level 2
Category Parts of C++ to Avoid
Status Checked
It is possible to compare old style enumerations with each other. Although there is no use to
compare such enumerations, the compiler won't warn about this because enumerations are
treated as integers.

Wrong example:

enum Color { red, yellow, blue };

enum Status { OK, NOK };

void m(Color col) {

if (col == OK) { // compiles fine, but is not intended
dosomething();
}
}

Right example:

enum Color { red, yellow, blue };

enum Status { OK, NOK };

void m(Color col) {

if (col == red) {
dosomething();
}
}

PCA#018

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 80/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Use functionality from the std library if possible

Level 5
Category Parts of C++ to Avoid
Status Checked
It is better to use the standard library std if possible because it minimizes the number of external
dependencies. For instance, since the introduction of C++11, a lot of Boost functionality is now
available from the standard library std.

Sometimes there is a one to one relation between std and Boost such as boost::bind that is
replaced by std::bind. But sometimes this relation is less trivial, e.g. to make a class non-
copyable one should derive from the boost::noncopyable class in the Boost case:

class X : private boost::noncopyable {};

whereas in C++11 this is done differently by using "delete" for the constructor and copy
constructor:

class X {
X(const X&) = delete;
X& operator=(const X&) = delete;
};

PCA#019
Synopsis Use string_view correctly
Level 5
Category Parts of C++ to Avoid
Status Checked
C++17 brings us std::string_view. It is a really useful tool: If you want to write a function
accepting some string, but does not need ownership, i.e. a view, use std::string_view. It supports
both const char* and std::string without any work, and does not involve any heap allocations.
Further, it clearly signals intent: this function takes a view. It doesn't own anything, it just views
it.

Yet there is one design decisions that warrants a discussion: std::string_view silently views
temporaries as well. This can create a problem if the view lives longer than the temporary, as the
view now views already destroyed data.

Check the following code:

std::string_view get_str() const

{
// substr starting at index 1 till the end

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 81/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

return my_str_.substr(1u);
}

The problem is that std::string::substr() - which is being called here, returns std::string; a
temporary std::string. So we're creating a view to a temporary object which will blow up as soon
as we try to use it.

Be careful when using std::string_view in return values. Ensure that the function doesn't return a
temporary. Be careful when calling std::string::substr().

Be very careful when storing a std::string_view somewhere, i.e. in a class object. Ensure that the
viewed string outlives the view.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 82/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Portability
ES.44
Synopsis Don't depend on order of evaluation of function arguments
Level 1
Category Portability
Status Checked

POR#001
Synopsis Never use absolute file paths
Level 3
Category Portability
Status Checked

POR#002
Synopsis Do not assume that an int and a long have the same size
Level 4
Category Portability
Status Unchecked
It depends on the compiler and platform used if this is the case.

POR#003
Synopsis Do not assume that a char is signed or unsigned
Level 4
Category Portability
Status Checked
In the definition of the C++ language, it has not yet been decided if a char is signed or unsigned.
This decision has instead been left to each compiler manufacturer. If this is forgotten and this
characteristic is exploited in one way or another, some difficult bugs may appear in the program
when another compiler is used. Use signed char when you want a one-byte signed numeric type,
and use unsigned char when you want a one-byte unsigned numeric type. Use plain old char
when you want to hold characters.

POR#004
Synopsis Do not cast a pointer to a shorter quantity to a pointer to a longer quantity
Level 1
Category Portability

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 83/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Status Checked
A processor architecture often forbids data of a given size to be allocated at an arbitrary
address. For example, a word must begin on an "even" address for MC680x0. If there is a pointer
to a char which is located at an "odd" address, a type conversion from this char pointer to an int
pointer will cause the program to crash when the int pointer is used, since this violates the
processor's rules for alignment of data. See also [Rule:CON#001].

POR#005
Synopsis Do not assume that pointers and integers have the same size
Level 1
Category Portability
Status Checked
It depends on the compiler and platform used if this is the case.

POR#006
Synopsis Use explicit type conversions for arithmetic using signed and unsigned values
Level 5
Category Portability
Status Checked
This way problems with the representation of signed and unsigned values in memory are
avoided.

POR#007
Do not assume that you know how an instance of a data type is represented in
Synopsis
memory
Level 3
Category Portability
Status Unchecked
The representation of data types in memory is highly machine-dependent. By allocating data
members to certain addresses, a processor may execute code more efficiently. Because of this,
the data structure that represents a class will sometime include holes and be stored differently in
different process architectures. Code that depends on a specific representation is, of course, not
portable.

POR#008
Synopsis Do not depend on underflow or overflow functioning in any special way
Level 4
Category Portability
Status Unchecked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 84/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

This depends on the compiler and platform used.

POR#009
Do not assume that longs, floats, doubles or long doubles may begin at arbitrary
Synopsis
addresses
Level 1
Category Portability
Status Unchecked
This depends on the compiler and platform used.

POR#010
Do not assume that the operands in an expression are evaluated in a definite
Synopsis
order, unless the order is specified in the language
Level 1
Category Portability
Status Unchecked
If a value is modified twice in the same expression, the result of the expression is undefined
except when the order of evaluation is guaranteed for the operators that are used. It is allowed
to use knowledge about the evaluation order of boolean expressions since this is specified in the
C++ language definition.

POR#011
Do not assume that you know how the invocation mechanism for a method or
Synopsis
function is implemented
Level 4
Category Portability
Status Unchecked
This depends on the compiler and platform used.

POR#012
Do not assume that static objects are initialized in any special order when they are
Synopsis
spread over multiple source files
Level 1
Category Portability
Status Unchecked
It is specified in C++ that static objects declared within one source file are initialized in the order
they are noted in that file. Usage of this knowledge is acceptable. However when multiple source
files are used to compose a module, the initialization order of static objects spread over multiple

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 85/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

source files is unpredictable. To solve this problem, it is acceptable when the initialization order
needs to be known to place related static objects in one source file.

POR#014
Synopsis Do not assume that a short is 16-bits
Level 6
Category Portability
Status Unchecked
According to [ref:Stroustrup], the size of a short is defined as smaller or equal than the size of an
int, but at least 16-bits. This means that the size of a short can be more than 16-bits. The size of
the Windows types SHORT and USHORT is defined as 16-bits.

POR#015
Synopsis Do not assume that a long is 32-bits
Level 6
Category Portability
Status Unchecked
According to [ref:Stroustrup], the size of a long is defined as greater or equal than the size of an
int, but at least 32-bits. This means that the size of a long can be more than 32-bits. The size of
the Windows types LONG and ULONG is defined as 32-bits.

POR#016
Synopsis Do not assume that the size of an enumeration is the same for all platforms
Level 5
Category Portability
Status Unchecked
According to [ref:Stroustrup] the size of an enumeration is the size of some integral type that
can hold its range and not larger than the size of an int. For instance, if the size of an int is 4, the
size of an enumeration can be 1, 2 or 4.

POR#017
Do not depend on undefined, unspecified, or implementation-defined parts of
Synopsis
the language
Level 1
Category Portability
Status Unchecked

POR#018

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 86/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Avoid the use of #pragma directives

Level 6
Category Portability
Status Checked

Exception 1:
The use of the #pragma preprocessor directive is allowed in specific files which special purpose
is to shield or implement platform dependent code. Such a #pragma shall be conditionally
defined based on a macro that identifies the platform. This makes the platform dependency
explicit. See also [Rule:POR#021].

Exception 2:
#pragma once is allowed to prevent multiple inclusion of a file. See also [Rule:ORG#001].

POR#019
Synopsis Header file names shall always be treated as case-sensitive
Level 5
Category Portability
Status Checked

POR#020
Synopsis Do not make assumptions about the exact size or layout in memory of an object
Level 2
Category Portability
Status Unchecked
As explained in ISC++, do not depend on specific size or layout assumptions. However, that
does not mean that object sizes are completely irrelevant: see also [Rule:OLC#011].

POR#021
Synopsis Avoid the use of conditional compilation
Level 6
Category Portability
Status Checked
Conditional compilation makes the flow of control harder to follow, and has ill effects on
testability. Platform dependencies should be handled using platform specific shadow files,
preferably located in a general platform building-block.

exceptions:

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 87/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Conditional compilation of header by means of include guards: [Rule:ORG#001].

Conditional application of platform dependent pragmas: see [Rule:POR#018].

An example of the last exception is:

#ifdef VXWORKS
#pragma SETPLATFORMSPECIFICOPTION
#endif

POR#022
Make sure all conversions from a value of one type to another of a narrower type
Synopsis
do not slice off significant data
Level 2
Category Portability
Status Unchecked

POR#025
Synopsis Floating point values shall not be compared using the == or != operators
Level 2
Category Portability
Status Checked
Due to rounding errors, most floating-point numbers end up being slightly imprecise. As long as
this imprecision stays small, it can usually be ignored. However, it also means that numbers
expected to be equal (e.g. when calculating the same result through different correct methods)
often differ slightly, and a simple equality test fails. For example:

float a = 0.15 + 0.15

float b = 0.1 + 0.2
if (a == b) // can be false!

Solutions to this problem that are not correct include:

!(a < b) && !(a > b)

and

fabs(a - b) < Double.Epsilon

Please read [Literature:Dawson] to understand how to solve this issue.

POR#028

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 88/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Synopsis Always return a value from main

Level 9
Category Portability
Status Checked
Note that the most portable values are EXIT_SUCCESS and EXIT_FAILURE, declared in <cstdlib>.

POR#030
Synopsis Both operands of the remainder operator shall be positive
Level 5
Category Portability
Status Unchecked
Please note that a % b is implementation-defined for negative a or b, and undefined for b == 0.
Also note that automatic verification of this rule is often impractical in case of signed types.

POR#031
Do not depend on implementation defined behavior of shift operators for built-in
Synopsis
types
Level 5
Category Portability
Status Checked
The right operand of a shift operator shall not be negative. The left operand of a shift operator
shall not be signed. Left shift operators may cause information loss by truncation.

POR#032
Synopsis Use nullptr instead of 0 or NULL for a null pointer
Level 9
Category Portability
Status Checked
Wrong example:

ptr = NULL;

Correct example:

ptr = nullptr;

POR#033
Synopsis Do not make assumptions on the size of int
Level 2

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 89/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Category Portability
Status Checked
This depends on the compiler and platform used.

POR#037
Synopsis Avoid the use of #pragma warning directive.
Level 1
Category Portability
Status Checked
To keep the code warning free, using #pragma warning directive is not allowed.

Exception: #pragma warning is allowed in header files *stdafx.h, such that external files can be
included, precompiled and controlled.

POR#038
Make sure that the sizes and types of functions are well-defined if exported to
Synopsis
other languages
Level 4
Category Portability
Status Unchecked
When exporting functions for use from other languages, make sure that the sizes of arguments
to these functions and the type of the return value are well-defined. Use the types of known size
that are provided by your language implementation ( e.g. uint32_t in C/C++11) or make use of
local typedefs that are available in your environment. Do not use types such as int, short or long
directly because these might have another size for other languages. For instance a long is 4
bytes in C++ on most platforms and 8 bytes in C#.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 90/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Preprocessor
PRE#001
Synopsis Do not define macros instead of constants, enums, or type definitions
Level 7
Category Preprocessor
Status Checked
A disadvantage of macros is that they can have side-effects and that they are not type-safe. In
C++ alternatives exists that do not have these drawbacks. An alternative for a macro constant is
the use of a const or enum, as in:

#define MAX_BUFFER_LENGTH 1000 // Not ok.

const ULONG ulMaxBufferLength = 1000; // Ok.
enum {MAX_BUFFER_LENGTH = 1000}; // Ok.

PRE#002
Synopsis Use parentheses around macro and macro parameters
Level 4
Category Preprocessor
Status Checked
If a macro can be used in an expression or the parameter passed to a macro can be an
expression, use parenthesis around them.

Consider a macro that calculates the square of number.

// Not allowed !!!

#define SQUARE(p) p * p

When the macro is used as follows:

SQUARE(5 + 2)

it is expanded into:

5 + 2 * 5 + 2

The result is 17 instead of 49.

To prevent such unexpected results, always use parentheses around the entire macro and macro
parameters, as in:

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 91/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

// OK
#define SQUARE(p) ((p) * (p))

An exception to this rule is when a macro is defined as a single token, as in:

// OK
#define SOMETHING SOMETHING_ELSE

PRE#003
Synopsis Be aware of side-effects when using macros
Level 1
Category Preprocessor
Status Unchecked
Assume we have the following macro:

#define MAX(a, b) ((a) > (b) ? (a) : (b))

When the macro is used as follows:

MAX(i++, j)

it is expanded as follows:

i++ > j ? i++ : j

If i is greater than j, it is incremented twice.

PRE#004
Do not use the preprocessor directive #define to obtain more efficient code;
Synopsis
instead, use inline or template methods/functions
Level 9
Category Preprocessor
Status Checked
An advantage of inline or template methods/functions is that they don't have side-effects as
macros have (see [Rule:PRE#003]). Another advantage is that inline or template
methods/functions are type-safe.

A macro "function" can be defined as a template function, as in:

#define MAX(p1, p2) (((p1) > (p2)) ? (p1) : (p2))

template<class T> T&

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 92/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Max(
const T& p1,
const T& p2);

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 93/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Static Objects
STA#001
Synopsis If a variable is not intended to change, make it a constant
Level 9
Category Static Objects
Status Unchecked
This way the compiler assures that the variable cannot be changed.

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 94/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Style
STY#002
Synopsis Always use parentheses to clarify the order of expression evaluation
Level 9
Category Style
Status Unchecked
Do not base the proper working on the C++ implicit evaluation order. Parentheses in
expressions improve the readability.

STY#017
Synopsis If a method/function has no formal parameter, do not use the keyword void
Level 9
Category Style
Status Checked
In C a function prototype without any parameters means that the function parameters are not
specified. The void keyword is used in C to indicate that the function has no parameters.
However, in C++ a method or function prototype without any parameters means that the
method or function does not have any parameters. The void keyword is no longer needed.

STY#020
Synopsis Use std::function instead of function pointers
Level 10
Category Style
Status Checked
A reason to use std::function is that it offers more flexibility to the user (caller of the function):
std::function accepts member- and free functions and accepts functions with bound extra
arguments.

Wrong example:

int foo(int x) { return x; }

int (*foo_func)(int) = &foo;

Right example:

int foo(int x) { return x; }

std::function<int(int)> foo_func = &foo;

more elegant:

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 95/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

std::function<int(int)> foo_func = [](int x) { return x; };

even more elegant:

auto foo_func = [](int x) { return x; };

STY#024
Synopsis The name of an #include guard shall contain at least the name of the header file.
Level 10
Category Style
Status Checked
If projects have files with the same name in different directories, it is not possible to include
both files. The guard of an internal header file must have an additional underscore appended at
the end. This is to prevent duplicate guard names when a certain interface is specified by both
an internal and external header file that have the same name. See also [Rule:ORG#001].

STY#025
Synopsis Do not use letters that can be mistaken for digits, and vice versa
Level 9
Category Style
Status Checked

STY#029
Synopsis Always provide an access specifier for class members
Level 9
Category Style
Status Checked

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 96/97
2024/11/27 下午6:57 Philips C++ Coding Standard (≥C++11)

Literature

https://csviewer.tiobe.com/#/ruleset/rules?status=CHECKED,UNCHECKED&tagid=i3rNOkyCQ9GvTNYPcm_4AA&setid=d4441hsNSnyvBQLp… 97/97