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
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
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
Constant Names
Function Names
- Regular functions camelcase. Start with captial letters
- Accessors/mutators lowercase + underscores
Enumerators
Comments
General
Class Comments
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
Tabs vs. Spaces
Conditionals
- Short if-statements in a single line
Variable and Array Initialization
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.
1.8.13