THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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
- Separate inline headers: We allow putting inline functions in separate files, using the suffix
-inline.h
or-impl.h
or.inline.h
.- Pros: ??
- Cons: ??
Scoping
- namespaces use of anonymous namespaces are not recommended.
- Pros: ??
- Cons: naming conflicts can occur between object files
- namespaces the
using namespace
directive is encouraged- Pros: reduces code volume
- Cons: pollutes the namespace, causes conflicts, makes it more difficult to determine the type of an object
Classes
- explicit ctors we do not mark single argument constructors
explicit
- Pros: None
- Cons: undesirable conversions
- copy ctors we do not implement or delete copy and assignment constructors
- Pros: easier use with the STL
- Cons: implicit copying of objects in C++ is a rich source of bugs and of performance problems
- operator overloading we extensively use operator overloading
- Pros: code looks nicer and is more compact
- 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.
- default function arguments we use default function arguments
- Pros: clean syntax, reduced code volumne
- Cons: function pointers are confusing in the presence of default arguments
- casting we use cast formats such as
int x = (int) y;
- Pros: clean syntax
- Cons: ambiguous operator
Formatting
- Line Length We use 90 character line lengths
- TODO Comments we do not include the name in the TODO comment
- 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. }