Skip to content

Guidelines

René Fonseca edited this page Jan 31, 2020 · 6 revisions

These guidelines apply to the Base Framework implementation and not third-party projects.

General

  1. Regardless of these guidelines the implementation MUST still be as compatible with third-party code as possible. Common issue is #define's with single word in third-party headers which may need to be #undef'ed.
  2. Do NOT include code copyrighted by other parties.

Style

  1. Use 2 spaces for indents. Do NOT use TABs.
  2. Always include EOL at end of files.
  3. Stay below 120 chars for line length.
  4. Methods and variables use thisIsMyMethod/thisIsMyVariable style.
  5. Constants including enum values use upper case THIS_IS_MY_CONSTANT style.
  6. Classes and enums use ThisIsMyClass/ThisIsMyEnum style.

Implementation

  1. Implementation is done in C++11 for high portability although later standards do have some nice features. Code MUST still be C++14 and C++17 compatible.
  2. Do NOT use new[] and delete[]. Use Allocator or similar classes instead if array is required. It is easy to add delete[]/delete mismatches.
  3. Use _throw/_rethrow instead of throw to allow runtime hook of thrown exceptions.
  4. Only throw types derived from Exception and always throw by value (not pointer).
  5. Only catch exceptions as mutable. E.g. catch (Exception& e) {}.
  6. Always initialize variables. Unless otherwise justified due to performance issues. Leave a comment in such cases.
  7. Avoid #define's and use enums whenever possible. Single word defines should be avoided completely to be naming clashes.
  8. In general all #define's use the long unique prefix COM_AZURE_DEV__BASE_. Only in special cases are we skipping the prefix.

Headers

  1. Use #pragma once to ensure single inclusion of header implementation.
  2. Do NOT include headers not required. If a header is included by another header then do not include it explicitly.
  3. Do NOT include third-party headers; besides a few exceptions that cannot be avoided due to C++ standard requirements.

Sources

  1. A header should generally be accompanied with a corresponding source file to simplify diagnostic of compile errors.
  2. Add a unit test when a new feature is added. See TEST_REGISTERin base/UnitTest.h.
  3. Third-party dependencies MUST be registered via MODULE_REGISTERin base/Module.h to allow automatic runtime detection of such dependencies.
Clone this wiki locally