This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

Automatic formatting

Our .clang-format file can be found in the repository and is the source of truth for how to deal with whitespace, except when clang-format's output greatly diverges from the style of the surrounding code or common sense. In that case, we should update the .clang-format file.

We aim to gradually adapt the codebase to the output of clang-format. Therefore we only recommend using it on lines that have non-whitespace changes. This can be accomplished with the git-clang-format tool.

Header Files

  1. Separate inline headers: We allow putting inline functions in separate files, using the suffix .inline.h. This can speed up compile times by reducing the volume of code to be compiled and reducing dependencies between headers.

Scoping

  1. namespaces the using namespace directive is allowed in .cc files in limited cases where it greatly reduces code volume.
    1. Pros: reduces code volume, less churn in "using namespace::class" directives.
    2. Cons: pollutes the namespace, causes conflicts, makes it more difficult to determine the type of an object

Commenting

Formatting

The .clang-format file checked into the Impala repository should be used to format whitespace (see Contributing to Impala for more info). The .clang-format file is the source of truth for whitespace formatting, except when its output significantly diverges from practices in the existing codebase or from common sense. In those cases .clang-format should be updated.

Some key differences from the Google C++ style are:

  1. Line Length We use 90 character line lengths
  2. Function Declaration we line wrap differently than Google, typically packing more parameters per line, e.g.:
// 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
  ...
}

 

    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.
}

Third-Party Libraries

  • Boost - we use a different set of Boost libraries. Reducing # of dependencies is encouraged and adding dependencies to new libraries should be carefully evaluated.
  • No labels