C++ Style Guide

Impala C++ Code follows a modified version of the Google C++ Style Guide at:

https://google.github.io/styleguide/cppguide.html

There are some key differences which are documented here.

Header Files

1. Separate inline headers: We allow putting inline functions in separate files, using the suffix -inline.h or -impl.h or .inline.h. 
   1. Pros: ??
   2. Cons: ??

Scoping

1. namespaces use of anonymous namespaces are not recommended.
   1. Pros: ??
   2. Cons: naming conflicts can occur between object files
2. namespaces the using namespace directive is encouraged
   1. Pros: reduces code volume
   2. Cons: pollutes the namespace, causes conflicts, makes it more difficult to determine the type of an object

Classes

1. explicit ctors we do not mark single argument constructors explicit
   1. Pros: None
   2. Cons: undesirable conversions
2. copy ctors we do not implement or delete copy and assignment constructors
   
   1. Pros: easier use with the STL
   2. Cons: implicit copying of objects in C++ is a rich source of bugs and of performance problems
3. operator overloading we extensively use operator overloading
   
   1. Pros: code looks nicer and is more compact
   2. Cons: It can fool our intuition into thinking that expensive operations are cheap, built-in operations. It is much harder to find the call sites for overloaded operators. Searching for Equals() is much easier than searching for relevant invocations of ==. Some operators work on pointers too, making it easy to introduce bugs. Foo + 4 may do one thing, while &Foo + 4 does something totally different. The compiler does not complain for either of these, making this very hard to debug.
4. default function arguments we use default function arguments
   
   1. Pros: clean syntax, reduced code volumne
   2. Cons: function pointers are confusing in the presence of default arguments
5. casting we use cast formats such as int x = (int) y;
   1. Pros: clean syntax
   2. Cons: ambiguous operator

Formatting

1. Line Length We use 90 character line lengths
2. TODO Comments we do not include the name in the TODO comment
3. Function Declaration we line wrap differently than google, for example do:

// Google Recommends:
ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1,  // 4 space indent
    Type par_name2,
    Type par_name3) {
  DoSomething();  // 2 space indent
  ...
}
// we use:
ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1, Type par_name2, Type par_name3) { // 4 space indent
  DoSomething();  // 2 space indent
  ...
}

// Google Recommends:
ReturnType ClassName::ReallyLongFunctionName(Type par_name1, Type par_name2,
                                             Type par_name3) {
  DoSomething();
  ...
}
// We use
ReturnType ClassName::ReallyLongFunctionName(Type par_name1, Type par_name2,
    Type par_name3) {  // 4 indents
  DoSomething();
  ...
}

    3. Conditionals we format conditionals as follows

// Google Recommends:
if (x == kFoo) return new Foo();
if (condition)
  DoSomething();  // 2 space indent.
if (condition) {
  DoSomething();  // 2 space indent.
}
// we only use:
if (x == kFoo) return new Foo();  // If the whole line fits into the 90 character limit
if (condition) {
  DoSomething();  // Otherwise, 2 space indent.
}