Skip to content

STYLE.md

Latest commit

 

History

History
93 lines (82 loc) · 11 KB

STYLE.md

File metadata and controls

93 lines (82 loc) · 11 KB

C++ CODE STYLE

These guidelines should be followed for all new C++ code in this repository.

The rules are based on some Google style rules.

Reviewers will be enforcing them, so please obey them.

Mandatory rules:

  1. Use .cpp extension instead of .cc
  2. Use "#pragma once" instead of #define guard
  3. No global variables (even const)
  4. Every .cpp file should have an associated .h file link.
  5. Guard all headers link.
  6. Includes order: related header -> C system includes (ABS order) -> C++ system includes (ABS order) -> other includes (ABS order) -> project includes (ABS order) -> conditional includes link.
  7. In constructors no virtual method calls or functions that can fail and if you can't signal an error link.
  8. No implicit conversions link.
  9. Make class data members private, unless they are static const link
  10. When defining a function, parameter order is: inputs, then outputs link
  11. All parameters passed to a function by reference must be labeled const link
  12. Use standard smart pointers when ownership can be transferred link
  13. Use prefix form (++i) of the increment and decrement operators with iterators and other template objects link
  14. Use a precise-width integer type from from <stdint.h> for all integer types and size_t and ptrdiff_t when required link
  15. Use 0 for integers, 0.0 for reals, nullptr for pointers, and '\0' for chars link
  16. Do not use non-standard extensions (exception: #pragma once) link
  17. No namespace aliases link
  18. Filenames should be all lowercase and can include underscores (_) link
  19. Type names or enumerators start with a capital letter and have a capital letter for each new word, with no underscores ("Camel Case") link
  20. The names of namespaces, functions/methods, variables (including function parameters), constants and data members are all lowercase, with underscores between words link
  21. Macros names are uppercase with underscores between the words: THIS_THIS_MY_CONSTANT link
  22. Each line of text in your code must be at most 120 characters long.
  23. Do not use any of non-ASCII characters link
  24. Use spaces, no tabs, and indent 2 spaces at a time link
  25. Return type on the same line as function name, and its parameters on the same line if they fit link
  26. Always use braces for: switch-case-blocks, while-loop and for-loop bodies; and no empty bodies for loops link
  27. No spaces around period or arrow in pointer or reference expression link
  28. Class sections in public, protected and private order, each indented one space link
  29. The contents of namespaces are not indented link

Recomended rules:

  1. Headers should be self-contained link.
  2. Use C++-style casts, or brace initialization for conversion of arithmetic types instead of C-like casts link
  3. Avoid forward declaration where possible link.
  4. Define inline functions when they are <= 10 lines link.
  5. Put the code in namespaces with unique names, but never use using directive link
  6. Put definitions that will not be used outside .cpp in unnamed namespace or declare them static (do not do that in headers) link.
  7. Place nonmember functions in a namespace link.
  8. Place a function's variables in the narrowest scope possible, and initialize variables in the declaration link.
  9. Static storage duration variables are allowed only if declared as constexpr and they are POD link.
  10. Do not make new classes copyable or movable link
  11. Prefer classes, not structs link
  12. Prefer composition on inheritance, but when inherinece is still required, then make it public link
  13. No multiple inheritance link
  14. Do not overload operators link
  15. In a class group similar declarations together, placing public parts earlier [link](Interface class should ha://google.github.io/styleguide/cppguide.html#Declaration_Order)
  16. No functions body longer than 60 lines, excluding comments and empty lines link
  17. No friend classes link
  18. Avoid using Run Time Type Information (RTTI) link
  19. Use const or constexpr where possible link
  20. Code should be 64-bit and 32-bit friendly link
  21. Avoid defining complex macros link
  22. Use sizeof(varname) instead of sizeof(type) link
  23. Use auto when it increases readability, but do not initialize an auto-typed variable with a braced initializer list link
  24. Avoid overcomplicated template programming link
  25. Do not define specializations of std::hash link
  26. Use C++11/14 features when needed, but no compile-time rational numbers (<ratio>), no <cfenv> and <fenv.h> headers and no ref-qualifiers on member functions link
  27. No abbreviations in naming, make the names self-descriptive link
  28. Use either the // or /* */ comment syntax, as long as you are consistent [link] (https://google.github.io/styleguide/cppguide.html#Comment_Style)
  29. If a .h declares multiple abstractions, the file-level comment should broadly describe the contents of the file, and how the abstractions are related link
  30. Every class declaration should have an accompanying comment that describes what it is for and how it should be used link
  31. Use function-wide comments for non-obvious functions link
  32. No variable (including function arguments) comments, use self-descriptive variable names instead link
  33. Add comments for tricky, non-obvious, interesting, or important parts of your code only link
  34. Pay attention to punctuation, spelling, and grammar in the comments link
  35. Use TODO or FIXME comments for code that is temporary, a short-term solution link
  36. Each line of text in your code should be less then 80 characters long link
  37. Format parameters and bodies of lambdas as for any other function, and capture lists like other comma-separated lists link
  38. Format a braced initializer list exactly like you would format a function call in its place link
  39. No spaces inside parentheses with one condition, one space after if, one space after closing paranthes, and put the if and else keywords on separate lines link
  40. No multiple variables in one declaration if those have pointer or reference decorations link
  41. When break long boolean expressions then put boolean operator at the end of the line link
  42. Never put trailing whitespaces at the end of a line link
  43. Do not use C++ exceptions is possible link

In all other cases use common sense and be consistent.