Coding Conventions - VirtualPhotonics/Vts.MonteCarlo GitHub Wiki

When contributing to the MCCL 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.

• Camel Case: Naming convention where the first letter of each word is capitalized with the exception of the first letter. Example: thisIsCamelCased
• 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 can be capitalized. Example: This_Is_Underscore_Delimited
  

These are the only naming conventions that should be used in the MCCL and apply to different aspects of the code defined below.

• Private fields should be prefixed with an underscore and camel cased (Note that at the start of the MCCL 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'.

Internal and external members should be grouped together in the source file and ordered as follows, Static should come before Instance:

• Events
• Fields
• Constructors
• Properties
• Public methods
• Private methods

Note: Regions should only be used if the source file is large, comments should be used to group the members.

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 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.
Example:

    if (a == 10)
    {
        //set the value of b
        b = 15;
    }
    else
    {
        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.
Example:

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

Spacing improves the readability of the source-code, follow these guidelines 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++)
    {
        Console.WriteLine(i);
    }

There are 2 types of comments in the code, XML comments and regular code comments. We use the XML comments to generate our XML Documentation, click here for more details.
The style for the code comments is two slashes // even for multi-line comments. Avoid using /* comments */

There should be one public type per source file but this file can contain multiple internal classes. Source files should have the same name as the public class in the file. Directory names should follow the namespace of the class.
The test projects should mirror the project they are testing in both structure and naming convention. There should be one test per class and it should be named the same as the class being tested and suffixed with the word Tests.
Example:
SolverFactory.cs is the name of the file for the public class SolverFactory
SolverFactoryTests.cs is the name of the file containing the tests