General coding standards for the VTP software

It is helpful if programmers contributing code to the VTP can try to apply the following.

1. C++ code formatting
   • Use tabs for indentation, 4 characters wide (this is the default for MSVC).
   • Open brace should be on its own line and line up with its matching closed brace.
   • Pointer and reference modifiers should appear adjacent to their symbol name, for consistency.  E.g.
     unsigned int *foo, *bar;
float &widget = ...;
not
     unsigned int* foo, *bar
float& widget = ...;
2. The standard C++ library should be used in its modern style, e.g.
   • #include <fstream>, not
   • #include <fstream.h>
3. Strings in vtdata code, and applications above it, should use a string class, either VTP's vtString or the C++ standard library's std::string as appropriate, rather than C-style (char *) strings.
4. As much as possible, C++ code should contain comments in a format readable by programs which automatically produce documentation, i.e. Doxygen.
5. Methods which can potentially fail, should return indication of success.  Throwing and catching of exceptions should be avoided except where truly necessary, such as interfacing to existing code which uses exceptions.

The following are practices to be beware, as they makes the code larger without making it clearer:

1. There should be no empty methods.
   • This includes constructors and destructors
   • Exception: base implementations for virtual methods which must provide a stub to avoid being pure.
2. Don't use "return" without argument at the end of a function; it is already the default behavior;
3. Don't use "const" for parameters of built-in types, e.g "const float" as a function argument.  It produces identical machine code, so its only effect is to make the source code bulkier and thus harder to maintain.
4. Don't use "this->" except where necessary (which is virtually never).

In case your own C++ coding practices differ, take a moment to consider that there are numerous widely-held religions in C++ coding which are based on incorrect assumptions, some based on popular programming books.  As an example, you can see some Notes on Effective C++ and More Effective C++.