C++ Core Guidelines

• The C++ code guidelines are a set of rules to use for modern C++ projects created by the C++ community.

• In the following section, we will list up the entries which are of considerable interest for this project.

• There will be some gaps in the number as we skipped some of the less importer ones.

• Also the code guidelines have gaps by default (blank space for new rules).

Philosophy

• P.1: Express ideas directly in code

• P.3: Express intent

• P.4: Ideally, a program should be statically type safe

• P.5: Prefer compile-time checking to run-time checking

• P.8: Don’t leak any resources

• P.9: Don’t waste time or space

• P.10: Prefer immutable data to mutable data

• P.11: Encapsulate messy constructs, rather than spreading through the code

Interfaces

• I.1: Make interfaces explicit

• I.4: Make interfaces precisely and strongly typed

• I.5: State preconditions (if any)

• I.7: State postconditions

• I.10: Use exceptions to signal a failure to perform a required task

• I.11: Never transfer ownership by a raw pointer (T*) or reference (T&)

• I.13: Do not pass an array as a single pointer

• I.23: Keep the number of function arguments low

• I.24: Avoid adjacent parameters of the same type when changing the argument order would change meaning

Functions and class methods

• F.1: “Package” meaningful operations as carefully named functions

• F.2: A function should perform a single logical operation

• F.4: If a function may have to be evaluated at compile time, declare it constexpr

• F.7: For general use, take T* or T& arguments rather than smart pointers

• F.15: Prefer simple and conventional ways of passing information

• F.16: For “in” parameters, pass cheaply-copied types by value and others by reference to const

• F.18: For “will-move-from” parameters, pass by X&& and std::move the parameter

• F.20: For “out” output values, prefer return values to output parameters

• F.21: To return multiple “out” values, prefer returning a struct or tuple

• F.26: Use a unique_ptr<T> to transfer ownership where a pointer is needed

• F.27: Use a shared_ptr<T> to share ownership

• F.43: Never (directly or indirectly) return a pointer or a reference to a local object

• F.45: Don’t return a T&&

• F.51: Where there is a choice, prefer default arguments over overloading

• F.55: Don’t use va_arg arguments

Classes

• C.2: Use class if the class has an invariant; use struct if the data members can vary independently

• C.3: Represent the distinction between an interface and an implementation using a class

• C.4: Make a function a member only if it needs direct access to the representation of a class

• C.7: Don’t define a class or enum and declare a variable of its type in the same statement

• C.8: Use class rather than struct if any member is non-public

• C.9: Minimize exposure of members

Enumerations

• Enum.1: Prefer enumerations over macros

• Enum.2: Use enumerations to represent sets of related named constants

• Enum.3: Prefer class enums over “plain” enums

• Enum.6: Avoid unnamed enumerations

• Enum.7: Specify the underlying type of an enumeration only when necessary

Resource management

• R.1: Manage resources automatically using resource handles and RAII (Resource Acquisition Is Initialization)

• R.2: In interfaces, use raw pointers to denote individual objects (only)

• R.3: A raw pointer (a T*) is non-owning

• R.4: A raw reference (a T&) is non-owning

• R.5: Prefer scoped objects, don’t heap-allocate unnecessarily

• R.10: Avoid malloc() and free()

• R.11: Avoid calling new and delete explicitly

• R.12: Immediately give the result of an explicit resource allocation to a manager object

• R.13: Perform at most one explicit resource allocation in a single expression statement

Classes

• C.30: Define a destructor if a class needs an explicit action at object destruction

• C.31: All resources acquired by a class must be released by the class’s destructor

• C.35: A base class destructor should be either public and virtual, or protected and non-virtual

• C.36: A destructor must not fail

• C.40: Define a constructor if a class has an invariant

• C.41: A constructor should create a fully initialized object

• C.42: If a constructor cannot construct a valid object, throw an exception

• C.43: Ensure that a copyable (value type) class has a default constructor

• C.44: Prefer default constructors to be simple and non-throwing

• C.46: By default, declare single-argument constructors explicit

• C.47: Define and initialize member variables in the order of member declaration

• C.49: Prefer initialization to assignment in constructors

• C.62: Make copy assignment safe for self-assignment

• C.64: A move operation should move and leave its source in a valid state

• C.65: Make move assignment safe for self-assignment

• C.80: Use =default if you have to be explicit about using the default semantics

• C.81: Use =delete when you want to disable default behavior (without wanting an alternative)

• C.82: Don’t call virtual functions in constructors and destructors

• C.90: Rely on constructors and assignment operators, not memset and memcpy

• C.129: When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance

• C.131: Avoid trivial getters and setters

• C.132: Don’t make a function virtual without reason

• C.133: Avoid protected data

Follow rule of 0 and rule of 5

• C.20 If you can avoid defining default operations, do

• C.21: If you define or =delete any copy, move, or destructor function, define or =delete them all

Performance

• Per.1: Don’t optimize without reason

• Per.2: Don’t optimize prematurely

• Per.3: Don’t optimize something that’s not performance critical

• Per.4: Don’t assume that complicated code is necessarily faster than simple code

• Per.5: Don’t assume that low-level code is necessarily faster than high-level code

• Per.6: Don’t make claims about performance without measurements

• Per.11: Move computation from run time to compile time