C++ Coding Standard: Class Design

Now the C++ coding standard gets into interesting territory: rules for classes.

• 6.1. Non-static data members must be private.
• 6.2. A class must implement at least one public constructor.
• 6.3. A class must declare its copy constructor and assignment operator.
  • 6.3.1. Exception to 6.3: not if declared private in base class.
• 6.4. Member functions which do not change data members must be declared "const".
• 6.5. Protected members should not be used.
• 6.6. Consider changing private member functions to anonymous namespace functions in the implementation file.
• 6.7. Classes must not declare "friend" classes.
• 6.8. Classes should not declare "friend" functions for non-inline functions.
• 6.9. Declare blank constructor if and only if a client needs it.
• 6.10. Consider calculating data instead of storing it.
• 6.11. Data members allocated on the heap must have type auto_ptr<T> or boost::shared_ptr<T>.
• 6.12. Member functions marked "const" must be idempotent.

Why are protected and friend disallowed? This is an idea I first encountered in the Lakos book. I don't recommend that book because of wacky stuff in it like external include guards, but his argument in this area is convincing: if you allow friend classes, you might as well make everything in the class public, because someone can just declare their own class with the same name as your friend, and access anything in your class. Similarly, to get access to protected members, all someone has to do is derive from your class. Protected members should usually just be public.

Rule 6.11 is a way to leak-proof your code. Obviously, for some applications shared pointers are going to take too much memory. But you should think seriously whether each class has austere memory requirements; if not, use shared pointers.

Next: class layout.