• Home
• com.teamscale
• teamscale-check-api
• 2024.8.0-rc2
• source code
• guideline-rules.tsv

×

Project download

Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance.
Project price only 1 $

You can buy this project and download/modify it how often you want.

META-INF.guidelines.cpp-core-guideline.guideline-rules.tsv Maven / Gradle / Ivy

ID in Guidelines	Readable Name	Category	Machine-checkable	Comments	Upstream URL
I:Interfaces	none	none
I.1	Make interfaces explicit	Interfaces
I.2	Avoid non-const global variables	Interfaces
I.3	Avoid singletons	Interfaces
I.4	Make interfaces precisely and strongly typed	Interfaces
I.5	State preconditions (if any)	Interfaces
I.6	Prefer Expects() for expressing preconditions	Interfaces
I.7	State postconditions	Interfaces
I.8	Prefer Ensures() for expressing postconditions	Interfaces
I.9	If an interface is a template, document its parameters using concepts	Interfaces
I.10	Use exceptions to signal a failure to perform a required task	Interfaces
I.11	Never transfer ownership by a raw pointer (T&)	Interfaces
I.12	Declare a pointer that must not be null as not_null	Interfaces
I.13	Do not pass an array as a single pointer	Interfaces
I.22	Avoid complex initialization of global objects	Interfaces
I.23	Keep the number of function arguments low	Interfaces	Yes
I.24	Avoid adjacent parameters that can be invoked by the same arguments in either order with different meaning	Interfaces	Yes
I.25	Prefer empty abstract classes as interfaces to class hierarchies	Interfaces
I.26	If you want a cross-compiler ABI, use a C-style subset	Interfaces
I.27	For stable library ABI, consider the Pimpl idiom	Interfaces
I.30	Encapsulate rule violations	Interfaces
F:Functions	none	none
F.1	“Package” meaningful operations as carefully named functions	Functions
F.2	A function should perform a single logical operation	Functions
F.3	Keep functions short and simple	Functions	Yes
F.4	If a function might have to be evaluated at compile time, declare it constexpr	Functions
F.5	If a function is very small and time-critical, declare it inline	Functions
F.6	If your function must not throw, declare it noexcept	Functions
F.7	For general use, take T& arguments rather than smart pointers	Functions
F.8	Prefer pure functions	Functions
F.9	Unused parameters should be unnamed	Functions	Yes
F.10	If an operation can be reused, give it a name	Functions
F.11	Use an unnamed lambda if you need a simple function object in one place only	Functions
F.15	Prefer simple and conventional ways of passing information	Functions
F.16	For “in” parameters, pass cheaply-copied types by value and others by reference to const	Functions
F.17	For “in-out” parameters, pass by reference to non-const	Functions
F.18	For “will-move-from” parameters, pass by std::move the parameter	Functions
F.19	For “forward” parameters, pass by std::forward the parameter	Functions
F.20	For “out” output values, prefer return values to output parameters	Functions
F.21	To return multiple “out” values, prefer returning a struct or tuple	Functions
F.60	Prefer T& when “no argument” is a valid option	Functions
F.22	Use T* or owner to designate a single object	Functions
F.23	Use a not_null to indicate that “null” is not a valid value	Functions
F.24	Use a span or a span_p to designate a half-open sequence	Functions
F.25	Use a zstring or a not_null to designate a C-style string	Functions
F.26	Use a unique_ptr to transfer ownership where a pointer is needed	Functions
F.27	Use a shared_ptr to share ownership	Functions
F.42	Return a T* to indicate a position (only)	Functions
F.43	Never (directly or indirectly) return a pointer or a reference to a local object	Functions
F.44	Return a T& when copy is undesirable and “returning no object” isn’t needed	Functions
F.45	Don’t return a T&&	Functions
F.46	int is the return type for main()	Functions
F.47	Return T& from assignment operators	Functions
F.48	Don’t return std::move(local)	Functions
F.49	Don’t return const T	Functions
F.50	Use a lambda when a function won’t do (to capture local variables, or to write a local function)	Functions
F.51	Where there is a choice, prefer default arguments over overloading	Functions
F.52	Prefer capturing by reference in lambdas that will be used locally, including passed to algorithms	Functions
F.53	Avoid capturing by reference in lambdas that will be used non-locally, including returned, stored on the heap, or passed to another thread	Functions
F.54	When writing a lambda that captures this or any class data member, don’t use [=] default capture	Functions
F.55	Don’t use va_arg arguments	Functions
F.56	Avoid unnecessary condition nesting	Functions
C: Classes and class hierarchies	none	none
C.1	Organize related data into structures (structs or classes)	Classes and class hierarchies
C.2	Use class if the class has an invariant; use struct if the data members can vary independently	Classes and class hierarchies
C.3	Represent the distinction between an interface and an implementation using a class	Classes and class hierarchies
C.4	Make a function a member only if it needs direct access to the representation of a class	Classes and class hierarchies
C.5	Place helper functions in the same namespace as the class they support	Classes and class hierarchies
C.7	Don’t define a class or enum and declare a variable of its type in the same statement	Classes and class hierarchies
C.8	Use class rather than struct if any member is non-public	Classes and class hierarchies
C.9	Minimize exposure of members	Classes and class hierarchies	Yes
C.10	Prefer concrete types over class hierarchies	Classes and class hierarchies
C.11	Make concrete types regular	Classes and class hierarchies
C.12	Don’t make data members const or references in a copyable or movable type	Classes and class hierarchies
C.20	If you can avoid defining default operations, do	Classes and class hierarchies
C.21	If you define or =delete any copy, move, or destructor function, define or =delete them all	Classes and class hierarchies
C.22	Make default operations consistent	Classes and class hierarchies
C.30	Define a destructor if a class needs an explicit action at object destruction	Classes and class hierarchies
C.31	All resources acquired by a class must be released by the class’s destructor	Classes and class hierarchies
C.32	If a class has a raw pointer (T*) or reference (T&), consider whether it might be owning	Classes and class hierarchies
C.33	If a class has an owning pointer member, define a destructor	Classes and class hierarchies
C.35	A base class destructor should be either public and virtual, or protected and non-virtual	Classes and class hierarchies	Yes
C.36	A destructor must not fail	Classes and class hierarchies
C.37	Make destructors noexcept	Classes and class hierarchies	Yes
C.40	Define a constructor if a class has an invariant	Classes and class hierarchies
C.41	A constructor should create a fully initialized object	Classes and class hierarchies
C.42	If a constructor cannot construct a valid object, throw an exception	Classes and class hierarchies
C.43	Ensure that a copyable class has a default constructor	Classes and class hierarchies
C.44	Prefer default constructors to be simple and non-throwing	Classes and class hierarchies
C.45	Don’t define a default constructor that only initializes data members; use in-class member initializers instead	Classes and class hierarchies
C.46	By default, declare single-argument constructors explicit	Classes and class hierarchies
C.47	Define and initialize member variables in the order of member declaration	Classes and class hierarchies
C.48	Prefer in-class initializers to member initializers in constructors for constant initializers	Classes and class hierarchies
C.49	Prefer initialization to assignment in constructors	Classes and class hierarchies
C.50	Use a factory function if you need “virtual behavior” during initialization	Classes and class hierarchies
C.51	Use delegating constructors to represent common actions for all constructors of a class	Classes and class hierarchies
C.52	Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization	Classes and class hierarchies
C.60	Make copy assignment non-virtual, take the parameter by const&, and return by non-const&	Classes and class hierarchies
C.61	A copy operation should copy	Classes and class hierarchies
C.62	Make copy assignment safe for self-assignment	Classes and class hierarchies
C.63	Make move assignment non-virtual, take the parameter by &&, and return by non-const&	Classes and class hierarchies
C.64	A move operation should move and leave its source in a valid state	Classes and class hierarchies
C.65	Make move assignment safe for self-assignment	Classes and class hierarchies
C.66	Make move operations noexcept	Classes and class hierarchies
C.67	A polymorphic class should suppress public copy/move	Classes and class hierarchies
C.80	Use =default if you have to be explicit about using the default semantics	Classes and class hierarchies
C.81	Use =delete when you want to disable default behavior (without wanting an alternative)	Classes and class hierarchies
C.82	Don’t call virtual functions in constructors and destructors	Classes and class hierarchies
C.83	For value-like types, consider providing a noexcept swap function	Classes and class hierarchies
C.84	A swap function must not fail	Classes and class hierarchies
C.85	Make swap noexcept	Classes and class hierarchies
C.86	Make == symmetric with respect to operand types and noexcept	Classes and class hierarchies
C.87	Beware of == on base classes	Classes and class hierarchies
C.89	Make a hash noexcept	Classes and class hierarchies
C.90	Rely on constructors and assignment operators, not memset and memcpy	Classes and class hierarchies
C.100	Follow the STL when defining a container	Classes and class hierarchies
C.101	Give a container value semantics	Classes and class hierarchies
C.102	Give a container move operations	Classes and class hierarchies
C.103	Give a container an initializer list constructor	Classes and class hierarchies
C.104	Give a container a default constructor that sets it to empty	Classes and class hierarchies
C.109	If a resource handle has pointer semantics, provide * and ->	Classes and class hierarchies
C.120	Use class hierarchies to represent concepts with inherent hierarchical structure (only)	Classes and class hierarchies
C.121	If a base class is used as an interface, make it a pure abstract class	Classes and class hierarchies	Yes
C.122	Use abstract classes as interfaces when complete separation of interface and implementation is needed	Classes and class hierarchies
C.126	An abstract class typically doesn’t need a user-written constructor	Classes and class hierarchies
C.127	A class with a virtual function should have a virtual or protected destructor	Classes and class hierarchies	Yes
C.128	Virtual functions should specify exactly one of virtual, override, or final	Classes and class hierarchies
C.129	When designing a class hierarchy, distinguish between implementation inheritance and interface inheritance	Classes and class hierarchies
C.130	For making deep copies of polymorphic classes prefer a virtual clone function instead of public copy construction/assignment	Classes and class hierarchies
C.131	Avoid trivial getters and setters	Classes and class hierarchies
C.132	Don’t make a function virtual without reason	Classes and class hierarchies
C.133	Avoid protected data	Classes and class hierarchies
C.134	Ensure all non-const data members have the same access level	Classes and class hierarchies
C.135	Use multiple inheritance to represent multiple distinct interfaces	Classes and class hierarchies
C.136	Use multiple inheritance to represent the union of implementation attributes	Classes and class hierarchies
C.137	Use virtual bases to avoid overly general base classes	Classes and class hierarchies
C.138	Create an overload set for a derived class and its bases with using	Classes and class hierarchies
C.139	Use final on classes sparingly	Classes and class hierarchies
C.140	Do not provide different default arguments for a virtual function and an overrider	Classes and class hierarchies
C.145	Access polymorphic objects through pointers and references	Classes and class hierarchies
C.146	Use dynamic_cast where class hierarchy navigation is unavoidable	Classes and class hierarchies
C.147	Use dynamic_cast to a reference type when failure to find the required class is considered an error	Classes and class hierarchies
C.148	Use dynamic_cast to a pointer type when failure to find the required class is considered a valid alternative	Classes and class hierarchies
C.149	Use unique_ptr or shared_ptr to avoid forgetting to delete objects created using new	Classes and class hierarchies
C.150	Use make_unique() to construct objects owned by unique_ptrs	Classes and class hierarchies
C.151	Use make_shared() to construct objects owned by shared_ptrs	Classes and class hierarchies
C.152	Never assign a pointer to an array of derived class objects to a pointer to its base	Classes and class hierarchies
C.153	Prefer virtual function to casting	Classes and class hierarchies
C.160	Define operators primarily to mimic conventional usage	Classes and class hierarchies
C.161	Use non-member functions for symmetric operators	Classes and class hierarchies
C.162	Overload operations that are roughly equivalent	Classes and class hierarchies
C.163	Overload only for operations that are roughly equivalent	Classes and class hierarchies
C.164	Avoid implicit conversion operators	Classes and class hierarchies
C.165	Use using for customization points	Classes and class hierarchies
C.166	Overload unary & only as part of a system of smart pointers and references	Classes and class hierarchies
C.167	Use an operator for an operation with its conventional meaning	Classes and class hierarchies
C.168	Define overloaded operators in the namespace of their operands	Classes and class hierarchies
C.170	If you feel like overloading a lambda, use a generic lambda	Classes and class hierarchies
C.180	Use unions to save memory	Classes and class hierarchies
C.181	Avoid “naked” unions	Classes and class hierarchies
C.182	Use anonymous unions to implement tagged unions	Classes and class hierarchies
C.183	Don’t use a union for type punning	Classes and class hierarchies
Enum: Enumerations	none	none
Enum.1	Prefer enumerations over macros	Enum
Enum.2	Use enumerations to represent sets of related named constants	Enum
Enum.3	Prefer class enums over “plain” enums	Enum
Enum.4	Define operations on enumerations for safe and simple use	Enum
Enum.5	Don’t use ALL_CAPS for enumerators	Enum	Yes
Enum.6	Avoid unnamed enumerations	Enum
Enum.7	Specify the underlying type of an enumeration only when necessary	Enum
Enum.8	Specify enumerator values only when necessary	Enum
R: Resource management	none	none
R.1	Manage resources automatically using resource handles and RAII (Resource Acquisition Is Initialization)	Resource management
R.2	In interfaces, use raw pointers to denote individual objects (only)	Resource management
R.3	A raw pointer (a T*) is non-owning	Resource management
R.4	A raw reference (a T&) is non-owning	Resource management
R.5	Prefer scoped objects, don’t heap-allocate unnecessarily	Resource management
R.6	Avoid non-const global variables	Resource management
R.10	Avoid malloc() and free()	Resource management
R.11	Avoid calling new and delete explicitly	Resource management
R.12	Immediately give the result of an explicit resource allocation to a manager object	Resource management
R.13	Perform at most one explicit resource allocation in a single expression statement	Resource management
R.14	Avoid [] parameters, prefer span	Resource management
R.15	Always overload matched allocation/deallocation pairs	Resource management
R.20	Use unique_ptr or shared_ptr to represent ownership	Resource management
R.21	Prefer unique_ptr over shared_ptr unless you need to share ownership	Resource management
R.22	Use make_shared() to make shared_ptrs	Resource management
R.23	Use make_unique() to make unique_ptrs	Resource management
R.24	Use std::weak_ptr to break cycles of shared_ptrs	Resource management
R.30	Take smart pointers as parameters only to explicitly express lifetime semantics	Resource management
R.31	If you have non-std smart pointers, follow the basic pattern from std	Resource management
R.32	Take a unique_ptr parameter to express that a function assumes ownership of a widget	Resource management
R.33	Take a unique_ptr& parameter to express that a function reseats the widget	Resource management
R.34	Take a shared_ptr parameter to express shared ownership	Resource management
R.35	Take a shared_ptr& parameter to express that a function might reseat the shared pointer	Resource management
R.37	Do not pass a pointer or reference obtained from an aliased smart pointer	Resource management
ES: Expressions and statements	none	none
ES.1	Prefer the standard library to other libraries and to “handcrafted code”	Expressions and statements
ES.2	Prefer suitable abstractions to direct use of language features	Expressions and statements
ES.3	Don’t repeat yourself, avoid redundant code	Expressions and statements
ES.5	Keep scopes small	Expressions and statements
ES.6	Declare names in for-statement initializers and conditions to limit scope	Expressions and statements
ES.7	Keep common and local names short, and keep uncommon and non-local names longer	Expressions and statements
ES.8	Avoid similar-looking names	Expressions and statements
ES.9	Avoid ALL_CAPS names	Expressions and statements
ES.10	Declare one name (only) per declaration	Expressions and statements	Yes
ES.11	Use auto to avoid redundant repetition of type names	Expressions and statements
ES.12	Do not reuse names in nested scopes	Expressions and statements
ES.20	Always initialize an object	Expressions and statements
ES.21	Don’t introduce a variable (or constant) before you need to use it	Expressions and statements
ES.22	Don’t declare a variable until you have a value to initialize it with	Expressions and statements
ES.23	Prefer the {}-initializer syntax	Expressions and statements
ES.24	Use a unique_ptr to hold pointers	Expressions and statements
ES.25	Declare an object const or constexpr unless you want to modify its value later on	Expressions and statements
ES.26	Don’t use a variable for two unrelated purposes	Expressions and statements
ES.27	Use std::array or stack_array for arrays on the stack	Expressions and statements	Yes
ES.28	Use lambdas for complex initialization, especially of const variables	Expressions and statements
ES.30	Don’t use macros for program text manipulation	Expressions and statements
ES.31	Don’t use macros for constants or “functions”	Expressions and statements
ES.32	Use ALL_CAPS for all macro names	Expressions and statements
ES.33	If you must use macros, give them unique names	Expressions and statements
ES.34	Don’t define a (C-style) variadic function	Expressions and statements
ES.40	Avoid complicated expressions	Expressions and statements
ES.41	If in doubt about operator precedence, parenthesize	Expressions and statements
ES.42	Keep use of pointers simple and straightforward	Expressions and statements
ES.43	Avoid expressions with undefined order of evaluation	Expressions and statements
ES.44	Don’t depend on order of evaluation of function arguments	Expressions and statements
ES.45	Avoid “magic constants”; use symbolic constants	Expressions and statements
ES.46	Avoid lossy (narrowing, truncating) arithmetic conversions	Expressions and statements
ES.47	Use nullptr rather than 0 or NULL	Expressions and statements
ES.48	Avoid casts	Expressions and statements
ES.49	If you must use a cast, use a named cast	Expressions and statements
ES.50	Don’t cast away const	Expressions and statements
ES.55	Avoid the need for range checking	Expressions and statements
ES.56	Write std::move() only when you need to explicitly move an object to another scope	Expressions and statements
ES.60	Avoid new and delete outside resource management functions	Expressions and statements
ES.61	Delete arrays using delete[] and non-arrays using delete	Expressions and statements
ES.62	Don’t compare pointers into different arrays	Expressions and statements
ES.63	Don’t slice	Expressions and statements
ES.64	Use the T{e} notation for construction	Expressions and statements
ES.65	Don’t dereference an invalid pointer	Expressions and statements
ES.70	Prefer a switch-statement to an if-statement when there is a choice	Expressions and statements
ES.71	Prefer a range-for-statement to a for-statement when there is a choice	Expressions and statements
ES.72	Prefer a for-statement to a while-statement when there is an obvious loop variable	Expressions and statements
ES.73	Prefer a while-statement to a for-statement when there is no obvious loop variable	Expressions and statements
ES.74	Prefer to declare a loop variable in the initializer part of a for-statement	Expressions and statements
ES.75	Avoid do-statements	Expressions and statements
ES.76	Avoid goto	Expressions and statements	Yes
ES.77	Minimize the use of break and continue in loops	Expressions and statements
ES.78	Don’t rely on implicit fallthrough in switch statements	Expressions and statements	Yes
ES.79	Use default to handle common cases (only)	Expressions and statements	Yes
ES.84	Don’t try to declare a local variable with no name	Expressions and statements
ES.85	Make empty statements visible	Expressions and statements	Yes
ES.86	Avoid modifying loop control variables inside the body of raw for-loops	Expressions and statements
ES.87	Don’t add redundant == or != to conditions	Expressions and statements	Yes
ES.100	Don’t mix signed and unsigned arithmetic	Expressions and statements
ES.101	Use unsigned types for bit manipulation	Expressions and statements
ES.102	Use signed types for arithmetic	Expressions and statements
ES.103	Don’t overflow	Expressions and statements
ES.104	Don’t underflow	Expressions and statements
ES.105	Don’t divide by integer zero	Expressions and statements
ES.106	Don’t try to avoid negative values by using unsigned	Expressions and statements
ES.107	Don’t use unsigned for subscripts, prefer gsl::index	Expressions and statements
Per: Performance	none	none
Per.1	Don’t optimize without reason	Performance
Per.2	Don’t optimize prematurely	Performance
Per.3	Don’t optimize something that’s not performance critical	Performance
Per.4	Don’t assume that complicated code is necessarily faster than simple code	Performance
Per.5	Don’t assume that low-level code is necessarily faster than high-level code	Performance
Per.6	Don’t make claims about performance without measurements	Performance
Per.7	Design to enable optimization	Performance
Per.10	Rely on the static type system	Performance
Per.11	Move computation from run time to compile time	Performance
Per.12	Eliminate redundant aliases	Performance
Per.13	Eliminate redundant indirections	Performance
Per.14	Minimize the number of allocations and deallocations	Performance
Per.15	Do not allocate on a critical branch	Performance
Per.16	Use compact data structures	Performance
Per.17	Declare the most used member of a time-critical struct first	Performance
Per.18	Space is time	Performance
Per.19	Access memory predictably	Performance
Per.30	Avoid context switches on the critical path	Performance
CP: Concurrency and parallelism	none	none
CP.1	Assume that your code will run as part of a multi-threaded program	Concurrency and parallelism
CP.2	Avoid data races	Concurrency and parallelism
CP.3	Minimize explicit sharing of writable data	Concurrency and parallelism
CP.4	Think in terms of tasks, rather than threads	Concurrency and parallelism
CP.8	Don’t try to use volatile for synchronization	Concurrency and parallelism
CP.9	Whenever feasible use tools to validate your concurrent code	Concurrency and parallelism
CP.20	Use RAII, never plain lock()/unlock()	Concurrency and parallelism
CP.21	Use std::lock() or std::scoped_lock to acquire multiple mutexes	Concurrency and parallelism
CP.22	Never call unknown code while holding a lock (e.g., a callback)	Concurrency and parallelism
CP.23	Think of a joining thread as a scoped container	Concurrency and parallelism
CP.24	Think of a thread as a global container	Concurrency and parallelism
CP.25	Prefer gsl::joining_thread over std::thread	Concurrency and parallelism
CP.26	Don’t detach() a thread	Concurrency and parallelism
CP.31	Pass small amounts of data between threads by value, rather than by reference or pointer	Concurrency and parallelism
CP.32	To share ownership between unrelated threads use shared_ptr	Concurrency and parallelism
CP.40	Minimize context switching	Concurrency and parallelism
CP.41	Minimize thread creation and destruction	Concurrency and parallelism
CP.42	Don’t wait without a condition	Concurrency and parallelism
CP.43	Minimize time spent in a critical section	Concurrency and parallelism
CP.44	Remember to name your lock_guards and unique_locks	Concurrency and parallelism
CP.50	Define a mutex together with the data it guards. Use synchronized_value where possible	Concurrency and parallelism
CP.51	Do not use capturing lambdas that are coroutines	Concurrency and parallelism
CP.52	Do not hold locks or other synchronization primitives across suspension points	Concurrency and parallelism
CP.53	Parameters to coroutines should not be passed by reference	Concurrency and parallelism
CP.60	Use a future to return a value from a concurrent task	Concurrency and parallelism
CP.61	Use async() to spawn concurrent tasks	Concurrency and parallelism
CP.100	Don’t use lock-free programming unless you absolutely have to	Concurrency and parallelism
CP.101	Distrust your hardware/compiler combination	Concurrency and parallelism
CP.102	Carefully study the literature	Concurrency and parallelism
CP.110	Do not write your own double-checked locking for initialization	Concurrency and parallelism
CP.111	Use a conventional pattern if you really need double-checked locking	Concurrency and parallelism
CP.200	Use volatile only to talk to non-C++ memory	Concurrency and parallelism
E: Error handling	none	none
E.1	Develop an error-handling strategy early in a design	Error handling
E.2	Throw an exception to signal that a function can’t perform its assigned task	Error handling
E.3	Use exceptions for error handling only	Error handling
E.4	Design your error-handling strategy around invariants	Error handling
E.5	Let a constructor establish an invariant, and throw if it cannot	Error handling
E.6	Use RAII to prevent leaks	Error handling
E.7	State your preconditions	Error handling
E.8	State your postconditions	Error handling
E.12	Use throw is impossible or unacceptable	Error handling
E.13	Never throw while being the direct owner of an object	Error handling
E.14	Use purpose-designed user-defined types as exceptions (not built-in types)	Error handling
E.15	Throw by value, catch exceptions from a hierarchy by reference	Error handling	Yes
E.16	Destructors, deallocation, swap, and exception type copy/move construction must never fail	Error handling
E.17	Don’t try to catch every exception in every function	Error handling
E.18	Minimize the use of explicit try/catch	Error handling
E.19	Use a final_action object to express cleanup if no suitable resource handle is available	Error handling
E.25	If you can’t throw exceptions, simulate RAII for resource management	Error handling
E.26	If you can’t throw exceptions, consider failing fast	Error handling
E.27	If you can’t throw exceptions, use error codes systematically	Error handling
E.28	Avoid error handling based on global state (e.g. errno)	Error handling
E.30	Don’t use exception specifications	Error handling
E.31	Properly order your catch-clauses	Error handling
Con: Constants and immutability	none	none
Con.1	By default, make objects immutable	Constants and immutability
Con.2	By default, make member functions const	Constants and immutability
Con.3	By default, pass pointers and references to consts	Constants and immutability
Con.4	Use const to define objects with values that do not change after construction	Constants and immutability
Con.5	Use constexpr for values that can be computed at compile time	Constants and immutability
T: Templates and generic programming	none	none
T.1	Use templates to raise the level of abstraction of code	Templates and generic programming
T.2	Use templates to express algorithms that apply to many argument types	Templates and generic programming
T.3	Use templates to express containers and ranges	Templates and generic programming
T.4	Use templates to express syntax tree manipulation	Templates and generic programming
T.5	Combine generic and OO techniques to amplify their strengths, not their costs	Templates and generic programming
T.10	Specify concepts for all template arguments	Templates and generic programming
T.11	Whenever possible use standard concepts	Templates and generic programming
T.12	Prefer concept names over auto for local variables	Templates and generic programming
T.13	Prefer the shorthand notation for simple, single-type argument concepts	Templates and generic programming
T.20	Avoid “concepts” without meaningful semantics	Templates and generic programming
T.21	Require a complete set of operations for a concept	Templates and generic programming
T.22	Specify axioms for concepts	Templates and generic programming
T.23	Differentiate a refined concept from its more general case by adding new use patterns.	Templates and generic programming
T.24	Use tag classes or traits to differentiate concepts that differ only in semantics.	Templates and generic programming
T.25	Avoid complementary constraints	Templates and generic programming
T.26	Prefer to define concepts in terms of use-patterns rather than simple syntax	Templates and generic programming
T.40	Use function objects to pass operations to algorithms	Templates and generic programming
T.41	Require only essential properties in a template’s concepts	Templates and generic programming
T.42	Use template aliases to simplify notation and hide implementation details	Templates and generic programming
T.43	Prefer using over typedef for defining aliases	Templates and generic programming
T.44	Use function templates to deduce class template argument types (where feasible)	Templates and generic programming
T.46	Require template arguments to be at least semiregular	Templates and generic programming
T.47	Avoid highly visible unconstrained templates with common names	Templates and generic programming
T.48	If your compiler does not support concepts, fake them with enable_if	Templates and generic programming
T.49	Where possible, avoid type-erasure	Templates and generic programming
T.60	Minimize a template’s context dependencies	Templates and generic programming
T.61	Do not over-parameterize members (SCARY)	Templates and generic programming
T.62	Place non-dependent class template members in a non-templated base class	Templates and generic programming
T.64	Use specialization to provide alternative implementations of class templates	Templates and generic programming
T.65	Use tag dispatch to provide alternative implementations of a function	Templates and generic programming
T.67	Use specialization to provide alternative implementations for irregular types	Templates and generic programming
T.68	Use {} rather than () within templates to avoid ambiguities	Templates and generic programming
T.69	Inside a template, don’t make an unqualified non-member function call unless you intend it to be a customization point	Templates and generic programming
T.80	Do not naively templatize a class hierarchy	Templates and generic programming
T.81	Do not mix hierarchies and arrays	Templates and generic programming
T.82	Linearize a hierarchy when virtual functions are undesirable	Templates and generic programming
T.83	Do not declare a member function template virtual	Templates and generic programming
T.84	Use a non-template core implementation to provide an ABI-stable interface	Templates and generic programming
T.100	Use variadic templates when you need a function that takes a variable number of arguments of a variety of types	Templates and generic programming
T.102	How to process arguments to a variadic template	Templates and generic programming
T.103	Don’t use variadic templates for homogeneous argument lists	Templates and generic programming
T.120	Use template metaprogramming only when you really need to	Templates and generic programming
T.121	Use template metaprogramming primarily to emulate concepts	Templates and generic programming
T.122	Use templates (usually template aliases) to compute types at compile time	Templates and generic programming
T.123	Use constexpr functions to compute values at compile time	Templates and generic programming
T.124	Prefer to use standard-library TMP facilities	Templates and generic programming
T.125	If you need to go beyond the standard-library TMP facilities, use an existing library	Templates and generic programming
T.140	If an operation can be reused, give it a name	Templates and generic programming
T.141	Use an unnamed lambda if you need a simple function object in one place only	Templates and generic programming
T.143	Don’t write unintentionally non-generic code	Templates and generic programming
T.144	Don’t specialize function templates	Templates and generic programming
T.150	Check that a class matches a concept using static_assert	Templates and generic programming
CPL: C-style programming	none	none
CPL.1	Prefer C++ to C	C-style programming
CPL.2	If you must use C, use the common subset of C and C++, and compile the C code as C++	C-style programming
CPL.3	If you must use C for interfaces, use C++ in the calling code using such interfaces	C-style programming
SF: Source files	none	none
SF.1	Use a .cpp suffix for code files and .h for interface files if your project doesn’t already follow another convention	Functions
SF.2	A header file must not contain object definitions or non-inline function definitions	Functions	Yes
SF.3	Use header files for all declarations used in multiple source files	Functions
SF.4	Include header files before other declarations in a file	Functions	Yes
SF.5	A .cpp file must include the header file(s) that defines its interface	Functions
SF.6	Use using namespace directives for transition, for foundation libraries (such as std), or within a local scope (only)	Functions	Yes
SF.7	Don’t write using namespace at global scope in a header file	Functions	Yes
SF.8	Use #include guards for all header files	Functions	Yes
SF.9	Avoid cyclic dependencies among source files	Functions
SF.10	Avoid dependencies on implicitly #included names	Functions
SF.11	Header files should be self-contained	Functions
SF.12	Prefer the quoted form of #include for files relative to the including file and the angle bracket form everywhere else	Functions
SF.13	Use portable header identifiers in #include statements	Functions
SF.20	Use namespaces to express logical structure	Functions
SF.21	Don’t use an unnamed (anonymous) namespace in a header	Functions
SF.22	Use an unnamed (anonymous) namespace for all internal/non-exported entities	Functions
SL: The Standard Library	none	none
SL.1	Use libraries wherever possible	The Standard Library
SL.2	Prefer the standard library to other libraries	The Standard Library
SL.3	Do not add non-standard entities to namespace std	The Standard Library
SL.4	Use the standard library in a type-safe manner	The Standard Library
SL.con.1	Prefer using STL array or vector instead of a C array	The Standard Library	Yes
SL.con.2	Prefer using STL vector by default unless you have a reason to use a different container	The Standard Library
SL.con.3	Avoid bounds errors	The Standard Library
SL.con.4	don’t use memset or memcpy for arguments that are not trivially-copyable	The Standard Library
SL.str.1	Use std::string to own character sequences	The Standard Library
SL.str.2	Use std::string_view or gsl::span to refer to character sequences	The Standard Library
SL.str.3	Use zstring or czstring to refer to a C-style, zero-terminated, sequence of characters	The Standard Library
SL.str.4	Use char* to refer to a single character	The Standard Library
SL.str.5	Use std::byte to refer to byte values that do not necessarily represent characters	The Standard Library
SL.str.10	Use std::string when you need to perform locale-sensitive string operations	The Standard Library
SL.str.11	Use gsl::span rather than std::string_view when you need to mutate a string	The Standard Library
SL.str.12	Use the s suffix for string literals meant to be standard-library strings	The Standard Library
SL.io.1	Use character-level input only when you have to	The Standard Library
SL.io.2	When reading, always consider ill-formed input	The Standard Library
SL.io.3	Prefer iostreams for I/O	The Standard Library
SL.io.10	Unless you use printf-family functions call ios_base::sync_with_stdio(false)	The Standard Library
SL.io.50	Avoid endl	The Standard Library
SL.C.1	Don’t use setjmp/longjmp	Classes and class hierarchies
Pro: Profiles	none	none
Type.1	Avoid casts	Type-safety profile
Type.2	Don't use static_cast to downcast	Type-safety profile
Type.3	Don’t use const_cast to cast away const	Type-safety profile
Type.4	Don’t use C-style (T)expression or functional T(expression) casts	Type-safety profile
Type.5	Don’t use a variable before it has been initialized	Type-safety profile
Type.6	Always initialize a data member	Type-safety profile
Type.7	Avoid naked union	Type-safety profile
Type.8	Avoid varargs	Type-safety profile
Bounds.1	Don’t use pointer arithmetic	Bounds safety profile
Bounds.2	Only index into arrays using constant expressions	Bounds safety profile
Bounds.3	No array-to-pointer decay	Bounds safety profile
Bounds.4	Don’t use standard-library functions and types that are not bounds-checked	Bounds safety profile
NL: Naming and layout suggestions	none	none
NL.1	Don’t say in comments what can be clearly stated in code	Naming and layout suggestions
NL.2	State intent in comments	Naming and layout suggestions
NL.3	Keep comments crisp	Naming and layout suggestions
NL.4	Maintain a consistent indentation style	Naming and layout suggestions
NL.5	Avoid encoding type information in names	Naming and layout suggestions
NL.7	Make the length of a name roughly proportional to the length of its scope	Naming and layout suggestions
NL.8	Use a consistent naming style	Naming and layout suggestions
NL.9	Use ALL_CAPS for macro names only	Naming and layout suggestions	Yes
NL.10	Prefer underscore_style names	Naming and layout suggestions
NL.11	Make literals readable	Naming and layout suggestions
NL.15	Use spaces sparingly	Naming and layout suggestions
NL.16	Use a conventional class member declaration order	Naming and layout suggestions
NL.17	Use K&R-derived layout	Naming and layout suggestions
NL.18	Use C++-style declarator layout	Naming and layout suggestions
NL.19	Avoid names that are easily misread	Naming and layout suggestions
NL.20	Don’t place two statements on the same line	Naming and layout suggestions
NL.21	Declare one name (only) per declaration	Naming and layout suggestions	Yes
NL.25	Don’t use void as an argument type	Naming and layout suggestions
NL.26	Use conventional const notation	Naming and layout suggestions
NL.27	Use a .cpp suffix for code files and .h for interface files	Naming and layout suggestions