Page MenuHomePhabricator

Coding Standards
Updated 90 Days AgoPublic

Here's a set of guidelines for C++ coding in Polutropon's projects:

  • Do not introduce Boost libraries as dependencies of your code
  • Generally avoid introducing huge dependencies in projects. Prefer lean and mean, minimalist tools.
  • Perfer the more "open" free software licenses (e.g: avoid GPL, prefer MIT)
  • Avoid using vendor specific tools and APIs. e.g: Do not use Direct3D, use OpenGL or Vulkan. Do not use DirectInput or X input, use SDL or OIS
  • Indent with tabs, tabs should have a width of 4 spaces in your environment
  • Use the Allman style for code indentation
  • Prefer to let the formatting of your code be done by tooling (clang-format)
  • Prefer modern C++ techniques
  • Perfer using auto
  • Strive for constcorrectness
  • Only use smart pointers for owning resources
  • Use standard containers from the STL
  • Use standard algorithms from the STL instead of rewriting your own
  • Use standard facilities from the standard library in priority. Example, use std::thread instead of e.g: SDL_thread
  • In cases there's no way of doing something with the standard library, start by looking if SDL2 support this. SDL2 is a great cross-platform "operating system API", and probably has as all the features you want
  • Prefer using this C++ wrapper for the SDL2
  • Keep the code either strictly cross platform, or guard platform specific code inside preprocessor defines. Attempt to wrap platform specific constructs in generic APIs.
  • never use using namespace in a header file. Avoid them in source files.
  • Recommendations from C++ Core Guidelines generally apply.
  • Handle errors by throwing exceptions, but don't make catching exceptions the norm. Generally try to trap them, log them, and and crash. We are not making medical equipment firmware, we are making games and other related software.
  • Try to put Doxygen style comments on your interfaces to facilitate creating API documentation. Prefer the /// marker.
  • Try to imitate the constructs used in existing code in projects
  • Do not use "type" prefixes in the names of struct, enum, classes and variables
  • Prefer snake_case in new code, instead of CamelCase
Last Author
Ybalrid
Last Edited
Feb 22 2019, 3:36 PM

Event Timeline

Ybalrid created this document.Feb 22 2019, 3:36 PM
Ybalrid edited the content of this document. (Show Details)