This project has moved and is read-only. For the latest updates, please go here.

Coding Conventions

When contributing to the VTS please follow the coding conventions detailed below. Some of the initial development did not adhere to these guidelines but going forward, this will be the code style and structure.

Naming Conventions


  • Camel Case: Naming convention where the first letter of each word is capitalized with the exception of the first letter. Example: thisTextIsCamelCased
  • Pascal Case: Naming convention where the first letter of each work is capitalized including the first letter. Example: ThisIsPascalCased
  • Underscore Delimited: Naming convention that places underscores between the words and the first letter of each word is capitalized. Example: This_Is_Underscore_Delimited

These are the only naming conventions that should be used in the VTS and apply to differnt aspects of the code defined below.
  • Private fields should be prefixed with an underscore and camel cased (Note that at the start of the VTS development these fields were Pascal cased but going forward they will be camel cased).
  • Member variables, parameters and local variables should be camel cased.
  • properties, functions, events, classes and protected variables should be Pascal cased.
  • Test methods should be underscore delimited.
  • Interfaces should be prefixed with an 'I'.

Code Ordering

Internal and external members should be ordered as follows and Static should come before Instance:
  • Events
  • Fields
  • Constructors
  • Properties
  • Public methods
  • Private methods


Code should be indented with 4 space characters, if a tab character is used, make sure your source-code editor replaces tabs with 4 spaces.


An opening brace " should appear on the next line after the start of a statement block and the code inside the brace should be indented 4 spaces. The closing brace " should be inline with the opening brace on it's own line.
    if (a == 10)
        //set the value of b
        b = 15;
        b = 25;

Braces should be used even when there is only a single line of code to avoid later issues if more code is added.

In cases where a statement can be on one line, braces can begin and end on the same line.
    string _myString

    public string MyString
        get { return _myString; }
        set { _myString = value; }


Spacing improves the readability of the source-code, follow these guidlines for spacing:

Use a space after the comma between arguments in a function
    MyFunction(FirstParam, SecondParam, 10, 5);

Use a space after statements like if, while, for and foreach
    if (a == 10)
        //set the value of b
        b = 15;

Use a space before and after operators with the exception of ++ and --
    for (i = 0; i <= 10; i++)


There are 2 types of comments in the code, XML comments and regular code comments. We use the XML comments to generate our programmer documentation, click here to see a description of the XML Comments.

The style for the code comments is two slashes // even for multi-line comments. Avoid using /* comments */

File Organization

Last edited Aug 20, 2010 at 6:57 AM by lmalenfant, version 1


No comments yet.