When dealing with configuration options that are known at compile time, if (...) constructs are preferred over conditional compilation. This enables the compiler to do more extensive checking of the possible code paths. For example:

          if (HAS_FOO)
            ...
          else
            ...
        

is preferred over conditional compilation:

          #ifdef HAS_FOO
          ...
          #else
          ...
          #endif
        

A way to achieve the former, when only presented with defines is shown below.

          #ifdef HAS_FOO
          const bool hasFoo = true;
          #else
          const bool hasFoo = false;
          #endif
        

One should be able to trust the compiler enough to optimise away the redundant variable hasFoo. Exceptions to the above rule almost exclusively deal with platform specific details. In such cases, a code path will only compile on the architecture for which the define checks. Attempting to check a code path that can never hope to compile in the first place, is futile.

Use standard prototype form. In definitions, left-align the name of the function and the open-brace that starts the body. According to the GNU Coding Standards, there are several tools that look for these names and their associated open-braces.

          int
          foo(int x, int y, short z,
              std::string& bar)
          {
            ...
          }
	

Because Microsoft Visual C++™ lacks the std::max() and std::min() templates, MesoRD defines its own. These templates are called MesoRD::max() and MesoRD::min(), respectively. For portability, one should use these MesoRD templates instead of whatever the current tool chain supplies.

When splitting expressions into multiple lines, split them before operators, not after.

C++ takes type-safety seriously: foo_t and foo_t* are viewed as distinct types, rather than the second just being a pointer to an object of the first kind. Spacing should be used to emphasise this view, by writing foo_t* bar, instead of foo_t *bar. In order to avoid confusion, pointers should be declared in separate statements. References, such as foo_t& are handled similarly.

Please put two spaces after the end of a sentence in comments, so that Emacs sentence commands work. Also, please write complete sentences and capitalise the first word.

When you have an if statement nested in another if statement, always put braces around the outer if.

Since NULL and 0 are really the same thing, one might as well save a macro expansion by using the simpler 0. In the documentation, the value is sometimes referred to as null, because it looks a bit clearer.

Make use of the MesoRD namespace.

Indentation level is two spaces. If you are using Microsoft Visual C++ select Options... from the Tools menu, pick Tabs and set Tab size and Indent size to 2. If you use Emacs, we can give you our hooks for C++ files.

We use doxygen to handle source-level documentation. Implementation specific comments go in the .cpp file, while the general descriptions end up in the .hpp file. Only the .hpp files are considered when building the documentation.