Notation

Rules

Class names shall start with a capital letter. Each word in the name shall be denoted with a capital letter. No underscores shall be used in class names.

Example: class CommandReturnType

Enum names shall follow the same naming convention as classes with one exception. The name of an enum shall end in “Enum.”

Example: enum CommandCodeEnum

Typedefs shall follow the same naming convention as classes with one exception. The name of a typedef shall end in “Type.”

Example: typedef uint8 CommandCodeType

All functions shall be named as follows:

Class methods shall start with a capital letter. Each word in the name shall be denoted with a capital letter. No underscores shall be used in method names.

Example: void CommandRegistry::Invoke( );

All method names shall begin with a verb.

Example: uint32 CommandHandler::GetEventTime();

Global functions shall start with a lowercase letter. Each word in the name shall be denoted with a capital letter. No underscores shall be used in function names.

Example: void commServerTask( );

All params shall be named as follows:

First letters of all parameter names shall be lowercase and all subsequent words shall begin with a capital letter.

Example void Command::Invoke(uint16 paramOne, char paramTwo);

Namespaces shall be subject to the following rules:

All modules shall define their code in a namespace that defines the functionality of the module. The namespace shall be named using the same convention as a class.

Example: namespace PhoenixCore

Example: namespacePhoenixCommServer

Built-in types shall be used as follows:

A char shall only be used when the programmer is referring to an ASCII character. If an 8-bit variable is desired, then the int8 or uint8 type shall be used.

An int shall only be used when the programmer is referring to a signedinteger. It is preferred that the programmer use the types int16, uint16, int32, uint32, as this disambiguates the size and sign of the variable.

Whenever an index is used in a loop, the type of the index shall reflect the objects being looped through. For example, when looping through a string and setting the loop variable to a character in the string, a char shall be used. When looping through an array, std::size_t shall always be used, as this guarantees that nowrap-around will occur.

All header files shall be commented as follows:

Each class, function, enum, file, or other object shall include a doxygen comment that describes the functionality of that object. All doxygen comments follow the rules below.

All doxygen comments shall follow one of two forms. For long comments, the doxygen comment shall start with /*! and end with */. Shorter comments can be placed on the same line as the object being commented (such as a class variable) and use the syntax /*!< Comment */

All functions including "//Constructor" and "//Destructor" shall be commented

All macros and defines shall be named in fully capital letters with underscores separating each word.

All tabs shall be inserted as 4 spaces. No tab characters shall be used in a source file.

All loops and conditional statements shall use the surrounding curly braces. Curly braces shall start on the line after the loop or conditional statement at the same indentation level as the statement. Code within the block shall be indented one level.

Case statements within a switch statement shall be placed at the same indentation level as the switch statement. Code within each case shall be indented one level.

At all times all checked-in code must compile with the settings for the Phoenix Eclipse project with no warnings or errors.

Lint will be used to check coding standards

All unit tests will be run during compilation.

No trailing whitespace allowed.

Line width shall be constrained to 80 characters per lines.

Between functions in .cpp files slashes shall be used to denote the split.