Coding Conventions

First, some general bits and bobs:

• Use names that describe the purpose or intent of the object.
• Write abbreviations as one word, e.g. myUrlVariable or startRpc() or UrlType
• Do not use exceptions; document failure values in function returns

Naming Conventions

• camelCase for functions, e.g. myAwesomeFunction()
• camelCase for function variables, e.g. myAwesomeVariable
• camelCase_ for class member variables, e.g. myAwesomeMemberVariable_
• CONSTANT_CASE for constants, e.g. MY_AWESOME_CONSTANT
• PascalCase for type names, e.g. MyAwesomeType

Documentation & Comments

• Comment code where the intent is unclear, e.g. an obscure hack that’s not well-documented
• Include Doxygen comments in header files along with function definitions
• As a general rule, make it so that your code requires as little comments as possible

Header Files

• All header files should start with #pragma once
• All dependencies should be directly included (no transitive dependencies)
  • Example: if ClassA.h includes ClassB.h and uses a file included in ClassB.h, that include should also be present in ClassA.h
• Avoid forward declaration where possible
  • DO: use forward declaration for a circular dependency
  • DO NOT: use forward declaration to hide a dependency
• Inline functions defined in the header should be 5 lines or less
  • DO: inline getters, setters and other one-liners
  • DO NOT: shove complex behavior into the header file
• Do not use using namespace xxx in header files (e.g. using namespace std)

Code Structure

• Static functions should be placed in a separate namespace, as opposed to in class definitions
  • Only use a static class function where the function is tightly bound to the class
• Each class has their own header (.h) and implementation file (.cpp)
  • Header-only classes do not need a corresponding .cpp file
  • Files are named after the class they implement (e.g. Burger is implemented in Burger.h and Burger.cpp)