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.
if(someExpression){
DoSomething();
}
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.
if(someExpression){
do{
DoSomething();
} 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:
DoSomething();
break;
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.
if(someExpression){
DoSomething();
}
DO indent case blocks even if not using braces.
switch(someExpression){
case 0:
DoSomething();
break;
...
}
Other
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
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.
//Avoid
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
...
#endregion
#region private members
...
#endregion
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;
...
