Thrill  0.1
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Coding Style Guide

In general we follow the Google C++ Style Guide.

Header Files

File Names

Header files end with .hpp, source files end with .cpp. All are lowercase, and CamelCase is transformed into camel_case with underscores.

Forward Declarations

  • You may and should forward declare classes in order to avoid unnecessary #includes

Inline Functions

  • No Restrictions on number of lines.
  • Either inside or outside classes

Function Parameter Ordering

  • First inputs, then outputs.
  • Prefix all output parameters with out_, no exceptions! -tb

Scoping

Namespaces

  • Don't use namespace std
  • Declare a project namespace
  • Unnamed Namespaces are a possibility
  • You can use the project namespace in applications
  • You should use only namespace thrill in test programs and use subnamespaces explicitly. This is because we may have duplicate class names in subnamespaces (e.g., Manager). -tb

Local Variables

  • Place a function's variables in the narrowest scope possible
  • Initialize variables in the declaration

Classes

  • Avoid doing complex initialization in constructors
  • If your object requires non-trivial initialization, use an init function

Initialization

  • Initialize everything!

Explicit Constructor

  • Use the C++ keyword explicit for constructors callable with one argument

Copyable and Movable Types

  • Disable copy and move when possible

Delegating and Inheriting Constructors

  • Use delegating and inheriting constructors

Structs and Classes

  • Use a struct only for passive objects that carry data
  • Everything else is a class

Inheritance

  • Composition is often more appropriate than inheritance
  • When using inheritance, make it public
  • Only very rarely is multiple inheritance actually useful! (Don't use it)

Interface

  • Only call something Interface if it is purely virtual

Operator Overloading

  • Don't use operator overloading!

Declaration Order

  • public, protected, private
  • Typedefs and Enums
  • Constants (static const data members)
  • Constructors
  • Destructor
  • Methods, including static methods
  • Data Members (except static const data members)

Write Short Functions

  • Everything over 40 lines has to do something useful!

C++ Features

Ownership and Smart Pointers

  • Avoid using raw-pointers and references
  • Use smart pointers!

Reference Arguments

  • All parameters passed by reference must be labeled const

Default Arguments

  • Use default arguments
  • Don't use function overloading

Exceptions

  • Don't use exceptions

Casting

  • Use C++ style casts (dynamic, static) when needed
  • Don't use C style casts

Use of const

  • const all the things!
  • Put it in front of declarations

Integer Types

  • Use types from <stdint.h> or size_t
  • Don't use int, long, ...!

auto

  • Use auto against clutter
  • Don't use auto for trivial types

Template metaprogramming

  • Template programming is allowed

Naming

Files Names

  • All lowercase
  • Underscores for separation

Type Names (Classes, Typedefs, etc.)

  • Camelcase
  • Start with captial

Variable Names

  • All lowercase
  • Underscores for separation

Class Data Members

  • Trailing underscores

Constant Names

  • k followed by mixed case

Function Names

  • Regular functions camelcase. Start with captial letters
  • Accessors/mutators lowercase + underscores

Enumerators

  • Treat like constants

Comments

General

  • Use Doxygen!

Class Comments

  • Leave aside

Implementation Comments

  • Describe function parameters if they are non trivial
  • Constants are a possibility for self-explanatory code

TODO Comments

  • Additionaly use Github/JIRA features

Formatting

Line length

  • 80 characters

Tabs vs. Spaces

  • Only spaces
  • 4 spaces

Conditionals

  • Short if-statements in a single line

Variable and Array Initialization

  • Initialize with ()

Class Format

  • private, public, protected on same line as class

Tests

No Randomization

  • do not use randomization in tests if at all avoidable.
  • if you use random integers, use a fixed random seed.
  • no randomization makes "this test if failing on my computer" more deterministic!

Include Files

  • never use #include <thrill/thrill.hpp> in a test! this file compiles everything (including future complex algorithms) and makes test compilation time needlessly long.