C++ Rules
Detailed Rule
Rule Topic
Do
Don't
Advice/Explanation
Rule ]
Header files
Create a dedicated header file for each C++ or C entity
Don't, for example, insert a global enum in a class header
file
This makes both client application programmer and CASE
tool job easier
Rule ]
#ifndef, #define, and #endifUse #ifndef, #define, and #endif
to enclose your header file content
Don't create a header file without them
This protects your code from header file multiple
inclusion
Rule ]
#includeUse #include judiciously
Don't, for example, include a class header file if a
pointer to this class is used as a method parameter
Improper uses of #include are useless and
unnecessarily increase code size. Advice : Use forward reference whenever possible
Rule ]
namespaceDon't use
This is not yet supported on every platform
Rule ]
Do not use threads
Don't use
Rule ]
Do not use templates
Don't use
They are not portable.
Rule ]
Multiple inheritance
Don't use
It is much more complex than single inheritance .Advice : Prefer the Object Modeler
Rule ]
Virtual inheritance
Don't use
Linked to multiple inheritance, which is already
forbidden
Rule ]
Public inheritance
Use it to derive classes
Don't use protected or private inheritance
This ensures that the base class members in the derived
class remain as they are defined in the base class, that is public,
protected, or private
Rule ]
friendDon't implement
It breaks encapsulation
Rule ]
Data member
Avoid to expose data members as public
It breaks encapsulation and forbids you to make your
implementation evolve
Rule ]
Static data member
Use it only if you need an instance counter
Generally avoid
They are shared by all instances of your classes
Rule ]
Constructors
For each class, provide by default:
This will help your clients assume that these
"basic" constructors always exist. Warning : Specific rule applies to extension classes.
Rule ]
Destructor
Declare the destructor as virtual for classes to derive
This will enable instances of derived classes to be
properly deleted
Rule ]
Virtual methods
Don't declare virtual methods within class private parts
This is useless
Rule ]
Virtual methods
Declare the methods intended to be redefined as virtual
This enables for class derivation
Rule ]
inline methodsAvoid
Every change in inlined code will force your client to
rebuild. Advice : You may do so only for proved gains (performance,
size).
Rule ]
Basic operators
Do not redefine
Except if it is obvious for everybody (complexes,
points)
Rule ]
Do not include non declarative code in header files
It is disastrous from a size perspective, and couples
your code with your clients code (they'll have to rebuild when you modify
this code)
Rule ]
Implicit casts
Do not use
Your clients should always be fully aware of the type
they manipulate
Rule ]
Parameter types
Use legal types only
This avoids problems with multi-platform and
multi-standard support, and distribution
Rule ]
constConstrain variables, arguments and methods by using const
const is a chance for your to express your
design intent to your clients. Don't miss it: they'll know if using your
method can alter an object state or not. Advice : Do it even even if you have to cast away the
constness of your pointers in your implementation for efficiency purposes.
Rule ]
Scope resolution operator (::)
Appropriately use the scope resolution operator (::)
Don't use it to access members inherited from classes above
the nearest base class
Rule ]
Exceptions
Use CATTry, CATCatch, and CATCatchOthers
to process existing exceptions
Don't create new exceptions
Lifecycle Rules
Detailed Rule
Rule Topic
Do
Don't
Advice/Explanation
Rule ]
Interface pointers
Use AddRef and Release appropriately
Rule ]
Other objects
Use new/delete and free/malloc appropriately
Rule ]
Available types
Rule ]
Pointer usage
Always initialize your pointers to NULL
Don't let pointers be initialized at random
Otherwise, this could lead to unexplainable memory
leaks
Rule ]
Pointer usage
Always test pointer values before using them
Never use a pointer before ensuring that it is not NULL
Otherwise, this could lead to core dumps
Rule ]
Pointers to objects
Always set pointers to deleted objects to NULL
Never let a valued pointer to a deleted object
Otherwise, this could lead to unexplainable memory
leaks and core dumps
Rule ]
Interface pointers
Always set release interface pointers to NULL
Never let a released but valued interface pointer
Otherwise, this could lead to unexplainable memory
leaks and core dumps
Object
Modeler
#
Rule Topic
Do
Don't
Advice/Explanation
Rule ]
Interface
Don't implement the same interface twice in the same
component
Otherwise, this could lead to unpredictable results
Rule ]
Interface OM-inheritance
Don't implement in a component an interface that OM-derives
from another interface already implemented in the same component
Otherwise, this could lead to unpredictable results
Rule ]
Extensions
Appropriately use data and code extensions
Don't use a data extension if it contains no data
Using code extension spares memory
Rule ]
Extensions and OM-inheritance
Always OM-derive your extensions from CATBaseUnknown or
CATnull
This is the only legal way of OM-deriving extensions
Rule ]
Extensions and C++-inheritance
Don't C++-derive extensions that implement several
interfaces
Otherwise, this could lead to unpredictable results
Rule ]
QueryInterfaceCorrectly use QueryInterface
This ensures to retrieve only valid interface pointers
Rule ]
Smart pointers
Do not use smart pointers
This avoids memory leaks
Rule ]
Smart pointers
Enable interface pointers and smart pointers to coexist
This avoids memory leaks
Rule ]
Interface dictionary
Correctly fill in the interface dictionary
Otherwise, the client application could not retrieve
interface pointers from your components, or worse, could retrieve wrong
interface pointers.
