Page MenuHomePhabricator

Coding Standards
Updated 747 Days AgoPublic

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

  • Avoid 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 (spaces for alignment)
  • 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 const correctness
  • Prefer 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, Win32 CreateThread or posix 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" layer, 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, but use your brain.
  • 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 for these (it's faster to type and easier on the eyes anyway).
  • 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. If you want to denote a member variable, prefer a _ sufix
  • Prefer snake_case in new code, instead of CamelCase
Last Author
Last Edited
Jan 6 2020, 4:10 PM

Event Timeline

Ybalrid edited the content of this document. (Show Details)
Ybalrid edited the content of this document. (Show Details)