CROSS Coding Guidelines

General Principles

When editing a file, try to follow the coding style that already exists in that file. Inconsistent style makes code hard to read and disorganized. Code should stress readability over conciseness.

Programming Model

We have worked very hard to develop CROSS as a modular, object-oriented, software platform. Please help us keep it that way! Do not re-implement classes and libraries when you can simply inherit from the ones already available and add functionality! We want to keep CROSS as easy to extend as possible, while minimizing code redundancy.

For more information on Object-Oriented Programming, see  OOP

Tabs and Spaces

All tabs should be 4 characters long, and should be replaced by spaces. Most modern editors have an option to replace tabs with spaces - make sure this is on at all times while editing VTCROSS code!

Note that this doesn't apply to tab-delimited languages, like 'Make'.

File Widths

Please limit files to 80 columns in length. If a line needs to be wrapped to the following line, please use '\' to delimit the break.

Variable Names

Variable names should be one string, lower-camel-cased: e.g. lowerCamelCased. Avoid using single-character variable names like 'c' for 'count'. Also, full words are preferred over concatenated versions - i.e. don't use 'shrt' over 'short'. Common abbreviations like 'num' and 'ptr' are acceptable.

Variable Typing

Only specified-width data typing should be used. These are defined by an IEEE standard, found here  stdint.h

To use these types, include <stdint.h> in your code. Examples of use:

• Instead of 'int', use 'int32_t'
• Instead of 'unsigned short', use 'uint16_t'

In addition, use the keyword 'NULL' over simply using '0' when using the NULL memory address.

Function and Class Declarations

Function and Class names should be one string, upper-camel-cased: e.g. UpperCamelCased?. Again, follow the guidelines for variable names regarding shortened forms of words.

Function return types should be on the line above the function name. Parameter lists should wrap before the 80th column:

int32_t
SomeClass::SomeFunction(int32_t argumentOne, int32_t argumentTwo, char argumentThree \
        char argumentFour) {
    ....
}

Parenthesis and Argument Lists

There should be no space between opening/closing parenthesis and text. For example, do NOT do this:

if ( conditional ) {
   ....
}

Instead, CROSS style looks like this:

if(conditional) {
   ....
}

Brackets

When defining functions or classes, brackets go on separate lines from the declaration:

void SomeFunction()
{
    ....
}

class SomeClass
{
    ....
};

For loop structures, the opening bracket should go on the same line as the conditional, and the closing bracket should be on it's own line:

if(conditional) {
    ....
}

if(conditional) {
    ....
} else if(conditional) {
    ....
} else {
    ....
}

while(conditional) {
    ....
}

do {
   ....
} while(conditional);

for(size_t i; i < variable; i++) {
    ....
}

Questions

If you have any questions about CROSS coding style or procedures, please get in touch with us!