Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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.
  2. Header include guards: for new code, we prefer #pragma once because it is cleaner than the classic #include guards

Variable Naming

We use UPPER_CASE for constants instead of kConstantName.

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

  • TODO Comments we typically do not include the name in the TODO comment. Where possible it's best to fix the TODO immediately (if it is a small task) or create a JIRA to track a more substantial improvement.

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

...