Rec. 3 An exception should routinely be granted whenever there are two classes that are tightly coupled, i.e., the use of one always requires the use of the other, such as a class and its unique containers, or the case of dual classes.
Rec. 3 An exception should routinely be granted whenever there are two classes that are tightly coupled, i.e., the use of one always requires the use of the other, such as a class and its unique containers, or the case of dual classes.
Rec. 6 Uniqueness should occur within the first eight characters to be
transportable to DOS.
Rule 6 addendum: Comments should be rigorously kept up to date; nothing is more destructive of productivity than out-of-date or misleading comments.
Rec. 9 Only tactical comments should be required to use //. There is nothing
wrong with the /* */ syntax for comments of large blocks. By the way, use of
/* */ for commenting out code is counterproductive. If it is necessary to
retain the text of an obsolete block of code, do so in a separate file. No
production or delivered code should have this kind of thing in it.
Rec. 20 Should be elevated to a rule.
Rec. 25 Should be elevated to a rule.
Rule 22 There is nothing wrong with const public member data. The practice of "casting away const" should be forbidden. In particular, the use of const
member data to save the object type in support of downcasting is particularly
helpful and robust.
It is worth noting that there is an attendant cost to the prohibition of protected data mambers, that is, each time a change requires a new accessor, the header file must be modified. Thinking ahead and providing const member data wherever possible has a big payoff.
Rec. 35 Operator overloading must also follow the sense of the precedence
rules.
Rule 29 This rule is, unfortunately, wrong. In general, of course, one does
not want outside influences to interfere with the data owned by the class.
But, surrogate objects of all kinds must grant write access to the
objects they encapsulate; it is part of their function and design. The whole
reason for surrogate classes is to improve the type-safety and access safety of
the types for which they substitute. Since the usage cannot be any safer,
within the confines of C++ coding, an exception must be granted for surrogate
classes. Certainly it is correct to point out in the comments that they are
surrogate classes, and that certain guidelines are recommended for their use.
Rec. 44 Should be elevated to a rule.