ES.5: Keep scopes small

Flag loop variable declared outside a loop and not used after the loop
Flag when expensive resources, such as file handles and locks are not used for N-lines (for some suitable N)

clang-tidy: readability-function-size

ES.6: Declare names in for-statement initializers and conditions to limit scope

Flag loop variables declared before the loop and not used after the loop
(hard) Flag loop variables declared before the loop and used after the loop for an unrelated purpose.

C++17 enforcement (if using a C++17 compiler)

Flag selection/loop variables declared before the body and not used after the body
(hard) Flag selection/loop variables declared before the body and used after the body for an unrelated purpose.

no enforcement

ES.7: Keep common and local names short, and keep uncommon and nonlocal names longer

Check length of local and non-local names. Also take function length into account.

no enforcement

ES.8: Avoid similar-looking names

Check names against a list of known confusing letter and digit combinations.
Flag a declaration of a variable, function, or enumerator that hides a class or enumeration declared in the same scope

no enforcement

ES.9: Avoid ALL_CAPS names

Flag all uses of ALL CAPS. For older code, accept ALL CAPS for macro names and flag all non-ALL-CAPS macro names.

no enforcement

ES.10: Declare one name (only) per declaration

Flag variable and constant declarations with multiple declarators (e.g., int* p, q;)

clang-format

ES.11: Use auto to avoid redundant repetition of type names

Flag redundant repetition of type names in a declaration.

clang-tidy: modernize-use-auto

ES.12: Do not reuse names in nested scopes

Flag reuse of a name in nested local scopes
Flag reuse of a member name as a local variable in a member function
Flag reuse of a global name as a local variable or a member name
Flag reuse of a base class member name in a derived class (except for function names)

no enforcement, maybe shadow declarations?

ES.20: Always initialize an object

Flag every uninitialized variable. Don't flag variables of user-defined types with default constructors.
Check that an uninitialized buffer is written into immediately after declaration. Passing an uninitialized variable as a reference to non-const argument can be assumed to be a write into the variable.

no enforcement

ES.21: Don't introduce a variable (or constant) before you need to use it

Flag declarations that are distant from their first use.

no enforcement

ES.22: Don't declare a variable until you have a value to initialize it with

Flag declarations with default initialization that are assigned to before they are first read.
Flag any complicated computation after an uninitialized variable and before its use.

no enforcement

ES.23: Prefer the {} initializer syntax

Tricky.
Don't flag uses of = for simple initializers.
Look for = after auto has been seen.

no enforcement

ES.24: Use a unique_ptr to hold pointers

Look for raw pointers that are targets of new, malloc(), or functions that may return such pointers.

clang-tidy: cppcoreguidelines-owning-memory

ES.25: Declare an object const or constexpr unless you want to modify its value later on

Look to see if a variable is actually mutated, and flag it if not. Unfortunately, it may be impossible to detect when a non-const was not intended to vary (vs when it merely did not vary).

no enforcement

ES.26: Don't use a variable for two unrelated purposes

Flag recycled variables.

no enforcement

ES.27: Use std::array or stack_array for arrays on the stack

Flag arrays with non-constant bounds (C-style VLAs)
Flag arrays with non-local constant bounds

no enforcement

ES.28: Use lambdas for complex initialization, especially of const variables

Hard. At best a heuristic. Look for an uninitialized variable followed by a loop assigning to it.

no enforcement

ES.30: Don't use macros for program text manipulation

Scream when you see a macro that isn't just used for source control (e.g., #ifdef)

no enforcement

ES.31: Don't use macros for constants or "functions"

Scream when you see a macro that isn't just used for source control (e.g., #ifdef)

no enforcement

ES.32: Use ALL_CAPS for all macro names

Scream when you see a lower case macro.

clang-tidy: readability-identifier-naming

ES.33: If you must use macros, give them unique names

Warn against short macro names.

no enforcement

ES.34: Don't define a (C-style) variadic function

Flag definitions of C-style variadic functions.
Flag #include and #include <stdarg.h>

clang-tidy: cppcoreguidelines-pro-type-vararg

ES.40: Avoid complicated expressions

side effects: side effects on multiple non-local variables (for some definition of non-local) can be suspect, especially if the side effects are in separate subexpressions
writes to aliased variables
more than N operators (and what should N be?)
reliance of subtle precedence rules
uses undefined behavior (can we catch all undefined behavior?)
implementation defined behavior?

no enforcement

ES.41: If in doubt about operator precedence, parenthesize

Flag combinations of bitwise-logical operators and other operators.
Flag assignment operators not as the leftmost operator.

no enforcement

ES.42: Keep use of pointers simple and straightforward

Flag any arithmetic operation on an expression of pointer type that results in a value of pointer type.
Flag any indexing expression on an expression or variable of array type (either static array or std::array) where the indexer is not a compile-time constant expression with a value between 0 or and the upper bound of the array.
Flag any expression that would rely on implicit conversion of an array type to a pointer type.

clang-tidy: cppcoreguidelines-pro-bounds-

ES.43: Avoid expressions with undefined order of evaluation

Can be detected by a good analyzer.

no enforcement

ES.44: Don't depend on order of evaluation of function arguments

Can be detected by a good analyzer.

no enforcement

ES.45: Avoid "magic constants"; use symbolic constants

Flag literals in code. Give a pass to 0, 1, nullptr, \n, "", and others on a positive list.

no enforcement

ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions

A good analyzer can detect all narrowing conversions. However, flagging all narrowing conversions will lead to a lot of false positives. Suggestions:

flag all floating-point to integer conversions (maybe only float->char and double->int. Here be dragons! we need data)
flag all long->char (I suspect int->char is very common. Here be dragons! we need data)
consider narrowing conversions for function arguments especially suspect

clang-sanitizers: -fsanitize=implicit-integer-truncation

ES.47: Use nullptr rather than 0 or NULL

Flag uses of 0 and NULL for pointers. The transformation may be helped by simple program transformation.

clang-tidy: modernize-use-nullptr

ES.48: Avoid casts

Force the elimination of C-style casts
Warn if there are many functional style casts (there is an obvious problem in quantifying 'many')
The type profile bans reinterpret_cast.
Warn against identity casts between pointer types, where the source and target types are the same (#Pro-type-identitycast)
Warn if a pointer cast could be implicit

clang-tidy: cppcoreguidelines-pro-type-const-cast, cppcoreguidelines-pro-type-cstyle-cast, cppcoreguidelines-pro-type-reinterpret-cast, cppcoreguidelines-pro-type-static-cast-downcast

ES.49: If you must use a cast, use a named cast

Flag C-style and functional casts.
The type profile bans reinterpret_cast.
The type profile warns when using static_cast between arithmetic types.

clang-tidy: same as in ES.48

core-check: C26475 NO_FUNCTION_STYLE_CASTS

ES.50: Don't cast away const

Flag const_casts.
This rule is part of the type-safety profile for the related Profile.

clang-tidy: cppcoreguidelines-pro-type-const-cast, cppcoreguidelines-pro-type-cstyle-cast

ES.55: Avoid the need for range checking

Look for explicit range checks and heuristically suggest alternatives.

clang-tidy: modernize-loop-convert

ES.56: Write std::move() only when you need to explicitly move an object to another scope

Flag use of std::move(x) where x is an rvalue or the language will already treat it as an rvalue, including return std::move(local_variable); and std::move(f()) on a function that returns by value.
Flag functions taking an S&& parameter if there is no const S& overload to take care of lvalues.
Flag a std::moves argument passed to a parameter, except when the parameter type is one of the following: an X&& rvalue reference; a T&& forwarding reference where T is a template parameter type; or by value and the type is move-only.
Flag when std::move is applied to a forwarding reference (T&& where T is a template parameter type). Use std::forward instead.
Flag when std::move is applied to other than an rvalue reference. (More general case of the previous rule to cover the non-forwarding cases.)
Flag when std::forward is applied to an rvalue reference (X&& where X is a concrete type). Use std::move instead.
Flag when std::forward is applied to other than a forwarding reference. (More general case of the previous rule to cover the non-moving cases.)
Flag when an object is potentially moved from and the next operation is a const operation; there should first be an intervening non-const operation, ideally assignment, to first reset the object's value.

no enforcement

ES.60: Avoid new and delete outside resource management functions

Flag naked news and naked deletes

clang-tidy: cppcoreguidelines-owning-memory

ES.61: Delete arrays using delete[] and non-arrays using delete

if the new and the delete is in the same scope, mistakes can be flagged.
if the new and the delete are in a constructor/destructor pair, mistakes can be flagged.

clang-static-analyzer: cplusplus.NewDelete
clang-tidy: clang-analyzer-cplusplus.NewDelete

ES.63: Don't slice

Warn against slicing.

clang-tidy: cppcoreguidelines-slicing

core-check: C26437 DONT_SLICE

ES.64: Use the T{e}notation for construction

Flag the C-style (T)e and functional-style T(e) casts.

no enforcement?, castingwarnings are done

ES.65: Don't dereference an invalid pointer

Flag a dereference of a pointer that points to an object that has gone out of scope
Flag a dereference of a pointer that may have been invalidated by assigning a nullptr
Flag a dereference of a pointer that may have been invalidated by a delete
Flag a dereference to a pointer to a container element that may have been invalidated by dereference

clang-tidy: bugprone-use-after-move, clang-analyzer-core.NullDereference
Adress Sanitizer, Memory Sanitizer, Thread Sanitizer, Undefined Behaviour Sanitizer

ES.70: Prefer a switch-statement to an if-statement when there is a choice

Flag if-then-else chains that check against constants (only).

no enforcement

ES.71: Prefer a range-for-statement to a for-statement when there is a choice

Look at loops, if a traditional loop just looks at each element of a sequence, and there are no side effects on what it does with the elements, rewrite the loop to a ranged-for loop.

clang-tidy: modernize-loop-convert

ES.73: Prefer a while-statement to a for-statement when there is no obvious loop variable

Flag actions in for-initializers and for-increments that do not relate to the for-condition.

no enforcement

ES.74: Prefer to declare a loop variable in the initializer part of a for-statement

Warn when a variable modified inside the for-statement is declared outside the loop and not being used outside the loop.

no enforcement

ES.75: Avoid do-statements

Flag do-statements.

no enforcement

ES.76: Avoid goto

Flag goto. Better still flag all gotos that do not jump from a nested loop to the statement immediately after a nest of loops.

core-check: C26438 NO_GOTO

clang-tidy: cppcoreguidelines-avoid-goto

ES.78: Always end a non-empty case with a break

Flag all fallthroughs from non-empty cases.

no enforcement

ES.79: Use default to handle common cases (only)

Flag switch-statements over an enumeration that don't handle all enumerators and do not have a default. This may yield too many false positives in some code bases; if so, flag only switches that handle most but not all cases (that was the strategy of the very first C++ compiler).