| Liquid Development Is What I Do
Seb Nilsson

C# Coding Style Conventions

From the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition).

I write this blog post as reference for myself and others. It's a summarized version of the chapter named 'C# coding style conventions' in above named book.

General Style Conventions

Brace usage

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

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

DO place the closing brace at the beginning of a new line.


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; }

CONSIDER single accessor properties having all brackets on the same line.

public int Foo{ get { return foo; } }

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

    } while(someOtherCondition);

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(i); }

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(...);

Another exception to the rule is braces in case statements. These braces can be omitted as the case and break statements indicate the beginning and the end of the block.

case 0:

Space Usage

DO use one space after the opening and before the closing of braces.

public int Foo{ get{ return foo; } }

AVOID using space before the opening braces.

Preferred:  if(someExpression){
Acceptable: if(someExpression) {

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)

AVOID using 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 space between a member name and opening parenthesis.

Right: Foo()
Wrong: Foo ()

DO NOT use spaces after or before the brackets.

Right: x = dataArray[index];
Wrong: x = dataArray[ index ];

DO NOT use spaces before flow control statements.

Right: while(x==y)
Wrong: while (x==y)

AVOID using space before and after binary operators.

Preferred:  if(x==y){ ... }
Acceptable: if(x == y){ ... }

DO NOT use space before or after unary operators.

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

Indent Usage

DO use 4 consecutive space characters for indents.

DO NOT use the tab character for indents

DO indent contents of code blocks.


DO indent case blocks even if not using braces.

    case 0:


CONSIDER using the var keyword whenever the resulting type of the variable is obvious. Avoid using it if it decreases readability.

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // probably not good; it's not clear what the type if id is

Naming Conventions

In general, we recommend following the Framework Design Guidelines for naming identifiers. However, there are some additional conventions and exceptions to using the Framework Design Guidelines for naming internal and private identifiers.

DO follow the Framework Design Guidelines for naming identifiers, except for naming private and internal fields.

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 type of a variable in its name).

AVOID prefixing local variables.

DO use C# aliases instead of Framework type names. For example, use int instead of Int32 and object instead of Object.


Comments should be used to describe the intent, algorithmic overview, and logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand the function's behavior and purpose. Although there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is desirable for most routines to have comments reflecting the programmer's intent and approach.

DO NOT use comments unless they describe something not obvious to someone other than the developer who wrote the code.

AVOID multiline syntax (/* --- */) for comments. The single-line syntax (// ...) is preferred even when a comment spans multiple lines.

DO NOT place comments at the end of a line unless the comment is very short.

public class ArrayList {
    private int count; // -1 indicates uninitialized array

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 is 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.

DO organize the directory hierarchy just like the namespace hierarchy. For example, the source file for System.Collections.Generic.List<T> should be in the System\Collections\Generic directory.

CONSIDER grouping members into the following sections in the specified order:

  • All fields
  • All constructors
  • Public and protected properties
  • Methods
  • Events
  • All explicit interface implementations
  • Internal members
  • Private members
  • All nested types

DO use #region blocks around not publicly callable and explicit interface implementation groups.

#region internal members
#region private members

CONSIDER organizing members of each group in alphabetical order.

CONSIDER organizing overloads from the simplest to the most complex.

DO place the using directives outside the namespace declaration

using System;

namespace System.Collections{

Own additions

DO place namespaces that are not included in .NET Framework on their own separate lines below the .NET Framework namespaces and all in alphabetical order.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Xml;

using MyNamespace;
using MyNamespace.SubNamespace;

Visual Studio: C#-Settings & StyleCop

Design Guidelines for .NET development is something very close and dear to me. Partially for my own sake, but mostly to have consistency across a company, between friends and maybe even across blog-examples.

The tool StyleCop is Microsoft's tool for enforcing these guidelines.

StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project.

After asking a question Visual Studio C#-settings and StyleCop (MS Source Analysis) on Stackoverflow I set out to try to get C# in Visual Studio to behave as compliant as possible.

The result after some testing around was this Visual Studio settings file. You can easily import these settings to your own Visual Studio.

It's mainly about placements of parentheses and curly-braces.

Yes, it can be a bit of a hassle to get used to having the curly-braces on the same line as the namespace-declaration, the class-declaration and method-declaration, but it saves some space and I got used to it quiet quickly and now have problems going back.

namespace TestApp {
    public class TestObject {
        static TestObject() {
            if(true) {
            } else {

This is as close as I can get to the conventions. It's worth to note that StyleCop can differ a bit from the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries .