High-level Rules that span many guidelines

[andralex]

The Core Guidelines advises e.g. using ranged for instead of for, for instead of while, and specialized ranged algorithms instead of either.

It also advises to stagger template definitions, avoid templates unless necessary, etc.

These and others are part of what I call the Rule of Minimum Power:

"Use the least amount of language power that gets the task done."

Under this specific strategic guideline fall a number of the concrete checkable guidelines. Then programmers seeing e.g.:

file.cpp(475): Rule of Minimum Power: use ranged for instead of explicit for loop.

will immediately understand the high-level motivation.

[andralex]

Another: Rule of Minimum State Access

"Minimize access to state at all points in the program."

This entails minimizing state itself and also access to it where present, by means of const views. This simple rule has good motivation from the FP experience and captures a ton of tactical rules:

Con.1: By default, make objects immutable
Con.2: By default, make member functions const
Con.3: By default, pass pointers and references to consts
Con.4: Use const to define objects with values that do not change after construction
I.2 Avoid global variables
F.20: Use a const T& parameter for a large object
C.6: Declare a member function that does not modify the state of its object const
R.6: Avoid non-const global variables
ES.21: Don't introduce a variable (or constant) before you need to use it (I'd formulate this as: "make variables as local as possible")
ES.22: Don't declare a variable until you have a value to initialize it with
ES.25: Declare an object const or constexpr unless you want to modify its value later on
(Unclassified) Use const'ness wherever possible: member functions, variables and (yippee) const_iterators

There's a mildly controversial one also caught by this:

• Prefer unnamed temporaries (rvalues) to variables

[andralex]

Rule of Superset of Subset:

Already defined and described by Bjarne. A few items already fit under this rule.

[andralex]

Rule of Earliest Checking

"Checking should occur as early as possible"

• Compile time better than link time
• Link time better than unittest time
• Unittest time better than contract time
• Contract time better than run time

[andralex]

Good example for Rule of Minimum Power: goto is the most powerful looping construct (it can do everything while does, and a lot more such as jumping in the middle of a loop etc.) and the most unrecommended.

[andralex]

Rule of Minimal Rigidity:

"Code should minimize lines touched per unit of meaningful change"

("Rigidity" here corresponds to the definition of Robert Martin)

• Using != over < in generic code falls under this rule (but also under RoMP).
• Coding for the weakest iterator also falls under this rule (but also under RoMP).
• The most important stand-alone incarnation: prefer auto to explicitly typed variables
  ** minimizes commitment to detail
• A number of more specialized tricks in template code are aimed at flexibility

This could be called Rule of Maximal Flexibility but "flexibility" is more vague and overloaded than "rigidity".

[andralex]

Rule of Ownership:

"All resources must be owned"

Owner means:

• A scope (for automatic, static, and namespace-level variables)
• An object, implicitly (direct field)
• An object, explicitly (unique_ptr, shared_ptr, vector, map, ...)
• A control flow (e.g. manual calls to malloc/free or fopen/fclose) - reduce to absolute minimum and use scope guards to help.

[FrankGorgenyi]

For the "Rule of Minimum Rigidity" favoring containment vs. inheritance is not mentioned. If inheriting an interface is not required for another reason encapsulating it with containment means as the type being contained changes your class will not. This minimizes code turn.

[BjarneStroustrup]

Added "immutability" under Philosophy.

[AndrewPardoe]

Herb will triage these and will discuss with editors and then create a PR. Many of these may fit into existing rules.

[AndrewPardoe]

Herb, please write this up. Also review R.1. Make note of "A control flow (e.g. manual calls to malloc/free or fopen/fclose) - reduce to absolute minimum and use scope guards to help."

[AstralStorm]

Preferring auto only makes sense in generic code and override makes things unreadable and hard to reason about as you no longer have a type system. Contacts will hopefully fix this allowing the use of a contract instead.

E.g. see random

for (auto foo : foos) {
  foo->do_stuff();
  do_stuff_with_foos();
}

Such a snippet will not tell you if foo is a pointer, an iterator, a pass by value with operator->, when it is invalidated and when it is safe to access foos and in what ways.
The best you can do here is to add a few ENSURE checks. Maybe.

Being explicit, on the other hand, will help. So better keep auto and decltype in generic code for now and replace with concepts when they become available.

Too reduce the load with std::vector::iterator and the like alias declarations (using) are available and proper IDE support is possible.