GSpace uses a documentation tool called Doxygen. Doxygen is a tool which is very similar a tool for Java called Javadoc. What it does, is based on comments within the code set, it creates various documentations for that source-code, allowing up to date documentation of the actual code structure at all times. To do this, however, Doxygen requires a strict way of commenting the actual code. GSpace uses two styles of comments throughout the code base. One using the javadoc method "/** */", this is where the Doxygen documentation goes. The other "//", is for general comments describing in code functionality. This allows for good separation of general comments and those meant for the official code documentation.

Comments are encouraged in any spot within the code, where it might not be clear to another developer what you are attempting to achieve. If you can't tell what code does at first glance, place a comment there. It saves both you and other developers' time later on down the track.

GSpace tries to use a very readable approach to variable naming. Rather then worrying about any forms of notations, practical names are preferred. For example, a integer which stores the X coordinate of a model, would be named ModelX.

A small amount of notation is used within the project:

• Suffix Ptr - This signifies that the variable is actually a pointer. This allows the user to quickly see pointers used within the code. For example a pointer to the X coordinate above would be ModelXPtr
• Prefix m_ - This signifies that the variable is actually a member variable. This means that when you are defining private variables within a class or struct, that you play the m_ before the variable. Example: m_ModelX
• Prefix C - Every class declaration should start with a C. This allows the user to quickly see the main class declaration, and later allows the developer to declare an instance of the class as a object with its full appropriate name without the C.
• A capital should be used to signify the starting of a new word for a variable. Underscores '_' are generally not used within the project in preference to the next word's first character being uppercase, except when using pre-processor definitions or const declarations. Const and pre-processor definitions should also be completely uppercase

Functions names should generally be a verb. For example, if the purpose of a function is to set a variable named UserID, then the function name should be SetUserID.

There is a lot of debate where you should place curly braces in your code. Each curly brace should be on the line after the statement, and the closing brace should line up with the opening brace.

For example:
int MyFunction()
{
...
}

The only exception to this rule is else/if and else statements. The opening curly brace should be on the same line as the else/if or else statement. The closing brace should be directly aligned with the first opening brace however.

For example:
if (false == MyVariable)
{
...
} else {
...
}