Skip to content

Coding standards

patrickfrancis edited this page Jan 29, 2015 · 6 revisions

These standards are taken from the Coding Style Conventions in the book Framework Design Guidelines, by Krzysztof Cwalina and Brad Abrams.

##Indent Usage Do use 4 consecutive space characters for indents.

Do Not use the tab character for indents.

Brace Usage

Do place the opening brace at the end of the preceding statement.

if(someExpression) {
    DoSomething();
}

Do align the closing brace with the beginning of the line containing the corresponding opening brace, unless closing a single-statement-block.

if(someExpression) {
    DoSomething();
}

Do place the closing brace on its own line unless followed by an else, else if, or while statement.

if(someExpression) {
    do {
        DoSomething();
    } while(someOtherCondition);
}

Consider single-statement-blocks that have braces that begin and end on the same line. Property accessors often use this style.

public int Foo {
    get { return foo; }
    set { foo = value; }
}

Avoid omitting braces, even if the language allows it.

Braces should not be considered optional. Even for single-statement-blocks, you should use braces. This increases code readability and maintainability.

for(int i = 0; i < 100; i++) { DoSomething(); }

There are very limited cases when omitting braces might be acceptable, such as when adding a new statement after an existing single-line statement is either impossible or extremely rare. For example, it is meaningless to add a statement after a throw statement:

if(someExpression) throw new ArgumentOutOfRangeException(...);

##Space Usage Do use one space after the opening and before the closing braces.

public int Foo { get { return foo; } }

Do use a single space after a comma between parameters.

Right: public void Foo(char bar, int x, int y)
Wrong: public void Foo(char bar,int x,int y)

Consider using a space between arguments.

Preferred:  Foo(myChar, 0, 1)
Acceptable: Foo(myChar,0,1)

Avoid using spaces after the opening or before the closing parentheses.

Preferred:  Foo(myChar, 0, 1)
Acceptable: Foo( myChar, 0, 1 )

Do Not use spaces between a member name and opening parenthesis.

Right: Foo()
Wrong: Foo ()

Avoid using spaces after or before brackets.

Preferred: x = dataArray[index];
Acceptable: x = dataArray[ index ];

Do Not use spaces before or after unary operators.

Right: if(!y) {...}
Wrong: if(! y) {...}

##Naming Conventions Do use PascalCasing for namespace, type, and member names, except for internal and private fields.

Do use camelCasing for private and internal fields.

Do use camelCasing for local variables.

Do use camelCasing for parameters.

Do Not use Hungarian notation (i.e. do not encode the tupe of a variable in its name).

Avoid prefixing local variables.

Do use C# aliases instead of .NET Framework type names.

For example, use int instead of Int32 and object instead of Object.

##File Organization Do Not have more than one public type in a source file, unless they differ only in the number of generic parameters or one is nested in the other.

Multiple internal types in one file are allowed.

Do name the source file with the name of the public type it contains.

For example, String class should be in String.cs file and List<T> class should be in List.cs file.

##Setting Options in Visual Studio Visual Studio's formatting options can be adjusted to comply with these coding standards. Open the Options dialog from the Tools->Options menu and navigate to the C# Formatting options. These can then be set as necessary. Visual Studio formatting screenshot

You can’t perform that action at this time.