Coding Standards
Written by Owen   
Thursday, 15 July 2010 15:32

Naming Standards

First letter of each word is capatilized. Applies to object (Classes, Enumerators, Aliases, etc) type names.
First letter of second and subsequent words are capatilized. Applies to any variables (class instances, pointers, references, etc).
First letter of second and subsequent words are capatilized. Applies to all functions except internal class functions.
An underscore is appended to the beginning of internal class member functions (those not intended to be used as a part of the public API but not used by end users).
All letters in the name are capitalized and words are seperated by underscores. Applies to Enumerator values and Macros.

General Guidelines for Naming

  • Use logical and verbose names.  Yes writing gV() is shorter than getValue(), but it is much more difficult to read and what the method does is not imeadiately obvious which can end up wasting more time looking up what the function does than would be saved by shaving off a few keystrokes.
  • Verboseness is good.  While comments are important, code should be self documenting.

Code Formatting Standards


Good Bad
if (one)
else if (two)

if (one)
if (one) doSomething();
else if (two) doSomethingElse();
else {


Good Bad
//Some simple comment. Describe something.

* Long multi-line comment, use sparingly.

/** Doxygen style brief description.
* Full Description.
* \author Owen Shelton
* \param val some passed value
* Bad, way too much work for a comment

// Same reason.

someCode(); //Nice idea, but poor readability.

Note that Doxygen is used to auto-generate documentation for the Onyx Framework and therefore their style of comments is preffered in everything but function bodies.  Information about Doxygen tags can be found here.


  • One class per file, with the class name being the same as the file name.
    • There are exceptions to this rule, such as when it makes logical sense to group multiple classes in a single file.  For examples see MessageBase.h and LogManagerCommands.h.
  • Files that contain only non-class objects must be named logically using the same naming convention as class declerations. 
  • Class decelerations go in header files, class definitions go in source files with the same name as the header.  Class member function definitions can go in header files when inlining is used or when it is necesary due to the use of templates.
    • In Implementation files, constructors and deconstructors are always defined first.  Any prvate, protected, or public member functions are then defined in the order they are listed in the header file.
Last Updated on Thursday, 15 July 2010 21:21

Login Form

Valid XHTML & CSS | Template Design ah-68 | Copyright © 2009 by Firma