Reason

• A cycle complicates the build process.
• Cycles are hard to understand and might introduce indeterminism (unspecified behavior).

Note

A library can contain cyclic references in the definition of its components. For example:

???

However, a library should not depend on another that depends on it.

NR: Non-Rules and myths

This section contains rules and guidelines that are popular somewhere, but that we deliberately don't recommend. We know perfectly well that there have been times and places where these rules made sense, and we have used them ourselves at times. However, in the context of the styles of programming we recommend and support with the guidelines, these "non-rules" would do harm.

Even today, there can be contexts where the rules make sense. For example, lack of suitable tool support can make exceptions unsuitable in hard-real-time systems, but please don't naïvely trust "common wisdom" (e.g., unsupported statements about "efficiency"); such "wisdom" might be based on decades-old information or experiences from languages with very different properties than C++ (e.g., C or Java).

The positive arguments for alternatives to these non-rules are listed in the rules offered as "Alternatives".

Non-rule summary:

• NR.1: Don't insist that all declarations should be at the top of a function
• NR.2: Don't insist on having only a single return-statement in a function
• NR.3: Don't avoid exceptions
• NR.4: Don't insist on placing each class definition in its own source file
• NR.5: Don't use two-phase initialization
• NR.6: Don't place all cleanup actions at the end of a function and goto exit
• NR.7: Don't make data members protected
• ???