-
Notifications
You must be signed in to change notification settings - Fork 8
style
Much of this information has been taken and condensed from the Google C++ Style Guide. Please use this as a reference and for further explanations for relevant sections. We do not include all sections in the style guide; unless otherwise noted however, the Google C++ Style Guide can be used for an explanation of a specific section as included here.
The goal of this guide is to manage this complexity by describing in detail the dos and don'ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively.
Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting.
In general, every .cpp file should have an associated .h file. Correct use of header files can make a huge difference to the readability, size and performance of your code.
All header files should be self-contained. Users and refactoring tools should not have to adhere to special conditions to include the header. Specifically, a header should have header guards and include all other headers it needs.
Prefer placing the definitions for template and inline functions in the same file as their declarations. The definitions of these constructs must be included into every .cpp file that uses them, or the program may fail to link in some build configurations. If declarations and definitions are in different files, including the former should transitively include the latter.
As an exception, a template that is explicitly instantiated for all relevant sets of template arguments, or that is a private implementation detail of a class, is allowed to be defined in the one and only .cpp file that instantiates the template.
All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be <ASPEN_<PATH>_<FILE>_H.
If the path is top-level, that is to say that if the file is located in src, there will be no path component.
For example, a header for foo.h in src would look like:
#ifndef ASPEN_FOO_H
#define ASPEN_FOO_H
...
#endifand a header for foo.h in src/bar would look like:
#ifndef ASPEN_BAR_FOO_H
#define ASPEN_BAR_FOO_H
...
#endifDo not use Forward Declarations when possible; simply include the header file.
Names and Order of Includes link to Names_and_Order_of_Includes
Use standard order for readability and to avoid hidden dependencies: Related header, C library, C++ library, other libraries' .h, your project's .h.
We divert from the style guide here; if you are including base/foo.h you may do so if your file is above base/foo.h or in the same directory. If you need to include foo.h and your file is in base/bar.h, you may use ../base/foo.h
Place a function's variables in the narrowest scope possible, and initialize variables in the declaration.
Avoid virtual method calls in constructors, and avoid initialization that can fail if you can't signal an error.
A class's public API should make explicit whether the class is copyable, move-only, or neither copyable nor movable. Support copying and/or moving if these operations are clear and meaningful for your type.
Use a struct only for passive objects that carry data; everything else is a class.
Composition is often more appropriate than inheritance. When using inheritance, make it public.
Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an
implementation; all other base classes must be pure interface classes tagged with the I prefix (ISerializable, for example.
Make data members private, unless they are static const
As Aspen is a smaller codebase, the Google Style documentation should be the fallback reference for anything not listed here. Where clarification or questions present themselves, further sections will be added to this document.