Modify Code

All constant names should be all upper case, regardless of how the constant is declared. That is, enums, defines, and variables with the const modifier should be named in all upper case.

Defines, enums, and const are all permitted and used throughout Trafodion, although most code in Trafodion uses enum for numerical constants and defines for character constants.

For new code, the use of const char or string is preferred for character constants instead of defines.

Namespace Names

AB characters are not permitted in source files except for text files (for example, makefiles) that require them.

Trafodion code uses several indenting depths, including 2, 3, 4, and 8 spaces. Most common is 2 and 3.

Use the style found in existing code, and when writing new code, use either 2, 3, or 4, and remain consistent.

A variety of control block indentation styles are used throughout Trafodion, most commonly Allman, Whitesmith, Stroustrup, and GNU. Follow the predominant style when making small to medium changes to existing code. For new code, the Allman style is preferred.

//Allman
   if (x > 5)
   {
      error = doThis(x);
      if (error != 0)
      {
         return false;
      }
   }
   else
   {
      doThat(x);
   }

//Whitesmith
   if (x > 5)
      {
      error = doThis(x);
      if (error != 0)
         {
         return false;
         }
      }
   else
      {
      doThat(x);
      }

//Stroustrup
   if (x > 5) {
      error = doThis(x);
      if (error != 0) {
          return false;
      }
   }
   else {
      doThat(x);
   }


Note that the Stroustrup and the similar K&R formats were popularized by usage in books where conservation of line count was a goal.

//GNU
  if (x > 5)
    {
      error = doThis(x);
      if (error != 0)
        {
          return false;
        }
    }
  else
    {
      doThat(x);
    }

Comments

Comment Style

Every file should have a comment at the beginning describing the purpose of the file.

In header files where classes are declared, there should be a comment describing the class, including purpose and usage. Also describe anything out of the ordinary, such as the use of multiple inheritance.

Within implementation files, in addition to the comment at the beginning of the file, add comments for any global or static variables defined in the file, and how the variable is handled in a multi-threaded environment (if applicable).

Also, for each function defined, describe the purpose and intent of the function. For each parameter, list whether it is input or output (or both), how it is used, and any range restrictions imposed. For functions not returning void, describe the possible return values.

Within the body of the function, there is no need to write comments that document the obvious. But if there is any complexity to the logic, at a minimum document the intent, and consider documenting the details (assumptions, limits, unexpected side effects from function calls, etc.)

If a feature is only partially implemented, add a comment indicating at a high level what work remains. Prefix the comment with //TODO.

//TODO Code is currently not thread safe.  Need to protect allocation of ...

Error Handling

Asserts

Don’t blindly cast to remove a compiler error or warning. Ensure the cast is safe.

Use const casting sparingly. Often the use of mutable or changing a function to be const correct is a better solution.

Types

Use standard types defined in <cstdint> or <stdint.h>. Note that Trafodion defines and uses many non-standard types (for example, Int32, Lng32), but this usage is being phased out.

Use types with explicit sizes (for example, int32_t, int64_t) when size is a factor in the code, such as an external API, or column in a table.

Where size is not a factor (counters, indexes) a non-sized type such as int or long may be used. However, in general, size_tand ssize_t are preferred for variables where fixed size is not required.