Difference between revisions of "Coding style"
(→Naming convention) |
|||
Line 1: | Line 1: | ||
− | This is a brief description of our coding style, roughtly following the [https://google.github.io/styleguide/cppguide.html Google C++ Style Guide]. | + | This is a brief description of our coding style, roughtly following the [https://google.github.io/styleguide/cppguide.html Google C++ Style Guide]. You can also download our code style guide to import in CLion |
=General= | =General= |
Revision as of 08:16, 14 November 2017
This is a brief description of our coding style, roughtly following the Google C++ Style Guide. You can also download our code style guide to import in CLion
General
A soft $80$ characters line width limit.
Indentation
Indent using spaces. Indentation width is $4$ spaces.
for (int i = 0; i < 10; i++) {
cout << i << endl;
}
Naming convention
Constants - UPPER_CASE
classes - PascalCase
methods - camelCase
variables and stand-alone functions - underscore_separated
typedefs - lowercase underscore separated, usually one word with trailing _t
, eg. vec_t
.
namespaces - one lowercase word, maybe shortened, eg. op
. For internal implementation details use op_internal
. Namespace closing brace should contain comment `// namespace your_name`. There is no indentation within namespaces.
All standard abbreviations like Moving Least Squres (MLS) or Finite Elements Method (FEM) -
UPPER_CASE
Floating point and integer literals use small suffixes, eg. 0.0f, -1e8l, 45ull
.
#define MAX_VALUE 500
class MyClass {
public:
MyClass(first_var, second_var) {
...
}
int getSize();
}
Comments
Comments are good. Use them to explain your code. Comments should have a space between the last slash and the start of text. Inline comments should have at least two spaces between end of code and start of the comment.
// This function will change the world
double change_the_world(bool skynet) {
if (skynet) {
return 0.0; // Brace for the end of the world
}
...
}
Use doxygen comments to generate documentation.
Headers
All headers must contain a header guard of form PATH_TO_FILENAME_HPP_
as enforced by the linter.
Includes in header guards are separated in two groups, with intra-project includes on top and other includes on the bottom. The groups are separated by a blank line and includes are kept sorted within a group.
Misc
Avoid trailing whitespace. Curly opening brackets {
should be inline with for
loops, function
definitions, class names, separated with a space. Outermost binary operators should have spaces
around them.
int sumMe(int var) { // yes
if (var == 1)
{ // no
return 1;
}
return 0;
}
For null pointer we use nullptr
instead of NULL
macro.