C# Coding Standard

Important: Use CSharpGuidelines for any topics not covered in this document.

The coding standard is primarily based on CSharpGuidelines (by Aviva Solutions) but differs from it in these ways:

Structure of the document is adapted from C# Coding Standards for .NET and C# Coding Style Guide.
Some examples were taken from other sources listed under References.

File Organization
Formatting
Naming Conventions
Commenting Conventions
Language Conventions
References

File Organization

1. Source file name and class name should always match.

MyClass.cs → public class MyClass { … }

2. Directory names should follow namespace for the class.

System.Windows.Forms.Control should use the path System\Windows\Forms\Control.cs

Note	Do not use namespace name with dots. This will make it easier to map namespaces to the directory layout.

Formatting

Layout

1. Avoid putting multiple namespaces or classes per file.

This will make your code more readable and also make it easier to find the .cs file for a particular class.

2. Place using directives at the top of the file, grouped and ordered alphabetically.

// .NET namespaces first
using System;
using System.Collections;

// Then any other namespaces in alphabetical order
using Company.Business;
using Company.Standard;

using Telerik.Ajax;
using Telerik.WebControls;

3. Maintain a common order for each file.

i. Member variable

ii. Constructors and Finalizer

iii. Nested Enums, Structs and Classes

iv. Properties

v. Methods

Note	Sequence declaration within type groups are based on StyleCop’s SA1202 ordering: `public, internal, protected internal, protected, private`.

Indentation

1. Basic indentation should be 4 spaces(not tabs).

// A Hello World! program in C#.
using System;

namespace HelloWorld
{
    class Hello
    {
        static void Main()
        {
            Console.WriteLine("Hello World!");
        }
    }
}

2. Maximum line length is 130 characters.

When an expression does not fit, follow the general guidelines:

Break after a comma
Break after an operator
Align the new line with the beginning of the expression at the same level on the previous line
Prefer higher-level breaks to lower-level breaks

Example of breaking up method calls:

longMethodCall(expr1, expr2,
               expr3, expr4, expr5);

longMethodCall(expr1, expr2
        ,expr3, expr4, expr5);

Example of breaking an arithmetic expression:

var result = a * b / (c - g + f) +
             4 * z;

var result = a * b / (c - g +
             f) + 4 * z;

The top one is preferred, since the break occurs outside the parenthesized expression, which is higher-level.

3. Always place curly braces on a new line.

This is known as the Allman style.

while (x == y)
{
    firstMethod();
    secondMethod();
}

lastMethod();

4. Always put curly braces even if it might not be required.

Such as having only one statement in the if clause. This is to enforce consistency.

if (x > y)
{
    doSomething();
}

White Space

1. General guidelines.

Keywords like if, while should be followed by a white space.
Semicolons in for statements should be followed by a white space.
Commas should be followed by a white space.
Add a white space around operators like +, -, == etc.
Do not add white space after ( and before ).

Examples:

a = (b + c) * d;

while (true) {

doSomething(a, b, c, d)

for (i = 0; i < 10; i++) {

a=(b+c)*d;

while(true){

doSomething(a,b,c,d)

for(i=0;i<10;i++){

Naming Conventions

1. All names should be written in English.

English is the preferred language for international development.

2. Use proper casing for language elements.

Note	Pascal casing: the first letter of every word is capitalized. Camel casing: the first letter of every word, except for the first word, is capitalized.

Language element Casing Example

Language element	Casing	Example
Class, Struct	Pascal	`AppDomain`
Interface	Pascal	`IBusinessService`
Enumeration type	Pascal	`ErrorLevel`
Enumeration values	Pascal	`FatalError`
Event	Pascal	`Click`
Private field	Camel	`listItem`
Protected field	Pascal	`MainPanel`
Constant field	Pascal	`MaximumItems`
Constant local variable	Camel	`maximumItems`
Read-only static field	Pascal	`RedValue`
Local variable	Camel	`listOfValues`
Method	Pascal	`ToString`
Namespace	Pascal	`System.Drawing`
Parameter	Camel	`typeName`
Type parameter	Pascal	`TView`
Property	Pascal	`BackColor`

Class, Struct

Pascal

AppDomain

Interface

Pascal

IBusinessService

Enumeration type

Pascal

ErrorLevel

Enumeration values

Pascal

FatalError

Event

Pascal

Click

Private field

Camel

listItem

Protected field

Pascal

MainPanel

Constant field

Pascal

MaximumItems

Constant local variable

Camel

maximumItems

Read-only static field

Pascal

RedValue

Local variable

Camel

listOfValues

Method

Pascal

ToString

Namespace

Pascal

System.Drawing

Parameter

Camel

typeName

Type parameter

Pascal

TView

Property

Pascal

BackColor

3. Avoid using abbreviations.

Unless the full name is excessive:

Avoid abbreviations longer than 5 characters.
Abbreviations must be widely known and accepted.
Use upper case for 2-character abbreviations, and Pascal Case for longer abbreviations.

UIControl
HtmlSource

UiControl
HTMLSource

4. Prefix boolean variables with `Can`, `Is`, or `Has`.

Examples: CanEvaluate, IsVisible, HasLicense.

Note	Avoid boolean variables that represent the negation of things. e.g., use `IsInitialized` instead of `IsNotInitialized`.

5. Do not include the parent class name within a property name.

Customer.Name

Customer.CustomerName

6. Do not use Hungarian Notation.

Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the variable. This style was used in early Windows programming, but is now obsolete.

Name
Colors

strName
ColorsEnum

Note	Exception: All fields and variable names that contain GUI elements like button should be postfixed with their type name without abbreviations. e.g., `cancelButton`, `nameTextBox`.

Commenting Conventions

1. General guidelines.

Place the comment on a separate line, not at the end of a line of code.
Begin comment text with an upper case letter.
Insert one space between comment delimiter (//) and comment text.
Use // or /// but never /* … */.
The length of comment should not exceed the length of code.

2. Document all public, protected and internal types and members.

Documenting your code allows Visual Studio to pop-up the documentation when your class is used somewhere else. You can form your documentation using XML tags.

/// <summary>
/// Get a value indicating whether the user has a license.
/// </summary>
/// <returns>
/// <c>true</c> if the user has a license; otherwise <c>false</c>.
/// </returns>
public bool HasLicense() { ... }

Language Conventions

1. Do not omit access modifiers.

Explicitly declare all identifiers with the appropriate access modifiers instead of allowing the default.

private void WriteEvent(string message)

void WriteEvent(string message)

2. Always use the built-in C# data type aliases, instead of the .NET common type system.

short
int
long
string

Int16
Int32
Int64
String

3. Only use var when the type is very obvious.

When the type of a variable is clear from the context, use var in the declaration.

var welcomeMessage = "This is a welcome message!";
var account = new Account();

Do not use var when the type is not apparent from the right side of the assignment.

int result = ExampleClass.ResultSoFar();

Note	To know more about when to use/not to use implicit typing read Uses and misuses of implicit typing.

4. Favor Object and Collection initializers over separate statements.

var startInfo = new ProcessStartInfo("myapp.exe");
{
    StandardOutput = Console.Output,
    UseShellExecute = true
};

var startInfo = new ProcessStartInfo("myapp.exe");
startInfo.StandardOutput = Console.Output;
startInfo.UseShellExecute = true;

References

C# Coding Coventions (C# Programming Guide) — From Microsoft
C# Coding Standards for .NET — By Lance Hunt
C# Coding Style Guide — By Mike Krüger
CSharpGuidelines — From Aviva Solutions