Yotam's C++ Guidelines

Obvious

• Modularity:
  • Do not use goto.
  • Global variables are bad. Exceptions to this are constant tables and variables that truly and significantly affects performance.
  • (May be controversial) Return from a function only from the end of its main block. It makes it more readable and good for setting debug break points.
• Activate compiler warning flags (-Wall of g++). Clean your code from all warnings. Even non important ones. Leaving them in will just discourage chasing away future crucial warnings.
• Make virtually all your classes' destructor virtual.
• Within your exported headers - minimize #includes directives.
  Assume a given a class Foo is declared in Foo.h. The following do not require inclusion of Foo.h:
  • Referring to Foo& or const Foo&
  • Referring to Foo* or const Foo*
  • Declaring a function that returns a Foo value.
  If a huge set of headers inclusion is needed, consider modifying your class to work via handle reference or pointer to a hidden implementation of a non exported class. There will be a tiny run time penalty of extra dereferencing. But compilation speed will be reduced. Frequently some compilations will actually not be needed, just relinking. With shared dynamic libraries even that may not be necessary.
• Use inline code in headers if the following conditions hold:
  • It is small.
  • It serves as simple documentation.
  • It does not cause any extra inclusion.
• Never use:
  delete this;
  The owner of on object should delete it - not the object itself.
• Do not use #define to define constants. You would do better with C++'s static const or enum. Your debugger will like them too.
• Avoid implementing a copy constructor as:

        Foo::Foo(const Foo& other) /* no explicit initialization */ {
           *this = other; // calls:  Foo& Foo::operator=(const Foo&)
        }
        

  It may work but remember:
  • Data members will be initialized with default constructors. It may be slow, it may do things you do not want.
  • If Foo contains pointers of owned data then you either:
    • Forgot to delete them in the implementation of assignment operator, thus getting a memory leak.
    • If your assignment operator does deletions as necessary, here it will perform deletion of some uninitialized data. Scary.
  Use initialization whenever you can (and keep the declaration order!).
• Learn STL and use it. For any given task you will have less lines of code (unless...). Find what to do in your spare time.
• Prefer the usage of ++iter to iter++. Especially when iter is a non trivial iterator such as in STL. When defining your own iterator type, be sure to define both iterators differently. After that lesson you will understand the difference.
• Read and follow Effective C++ and more.

• Avoid Exceptions. I never wrote one though I do have to maintain some. I believe in good old return codes.
  OK, I can accept some exceptions when they follow their semantic. That is dealing with truly exceptional case. Such as memory allocation failure or a case that must not happen but just too complex to prove so. For example, file opening failure should not throw an exception.
• Avoid Microsoft's Visual C++ if you can. It is one of the weakest C++ compilers. A C++ compiler comparison shows this. Judging C++ and its standard libraries using it is unfair.
  There are many perfect C++ code examples which Visual C++ is just too stupid to handle.

Style

• In your team, do not try to force style. You will get more flames and less respect. Do recommend some reasonable suggestions.
• Try to fit functions within a screen. On old text terminals this used to be 24 lines! Now with small fonts and big screens you can triple this.
• The following:

  
         for(int i=0,i1=1;i!=INT_MAX;i=i1,++i1)cout<<"i="<<i<<endl;
         

  is uglier than

  
         for (int i = 0, i1 = 1;  i != INT_MAX; i = i1, ++i1)
         {
            cout << "i=" << i << endl;
         }