Technotes, HowTo Series
C# Coding Style Guide
Version 0.3
by Mike Krüger icsharpcode.net



About the C# Coding Style Guide
File Organization
Indentation
Comments
Declarations
Statements
White Space
Naming Conventions
Programming Practices
Code Examples
1. About the C# Coding Style Guide
This document may be read as a guide to writing robust and reliable programs. It focuses on programs written in C#, but many of the rules and principles are useful even if you write in another programming language.

2. File Organization
2.1 C# Sourcefiles
Keep your classes/files short, don't exceed 2000 LOC, divide your code up, make structures clearer. Put every class in a separate file and name the file like the class name (with .cs as extension of course). This convention makes things much easier.

2.2 Directory Layout
Create a directory for every namespace. (For MyProject.TestSuite.TestTier use MyProject/TestSuite/TestTier as the path, do not use the namespace name with dots.) This makes it easier to map namespaces to the directory layout.

3. Indentation
3.1 Wrapping Lines
When an expression will not fit on a single line, break it up according to these general principles:

Break after a comma.
Break after an operator.
Prefer higher-level breaks to lower-level breaks.
Align the new line with the beginning of the expression at the same level on the previous line
Example of breaking up method calls:

longMethodCall(expr1, expr2,
expr3, expr4, expr5);
Examples of breaking an arithmetic expression:


PREFER:

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

BAD STYLE – AVOID:

var = a * b / (c - g +
f) + 4 * z;
The first is preferred, since the break occurs outside the paranthesized expression (higher level rule). Note that you indent with tabs to the indentation level and then with spaces to the breaking position in our example this would be:

> var = a * b / (c - g + f) + > ......4 * z;
Where '>' are tab chars and '.' are spaces. (the spaces after the tab char are the indent with of the tab). A good coding practice is to make the tab and space chars visible in the editor which is used.

3.2 White Spaces
An indentation standard using spaces never was achieved. Some people like 2 spaces, some prefer 4 and others die for 8, or even more spaces. Better use tabs. Tab characters have some advantages:

Everyone can set their own preferred indentation level
It is only 1 character and not 2, 4, 8 … therefore it will reduce typing (even with smartindenting you have to set the indentation manually sometimes, or take it back or whatever)
If you want to increase the indentation (or decrease), mark one block and increase the indent level with Tab with Shift-Tab you decrease the indentation. This is true for almost any texteditor.
Here, we define the Tab as the standard indentation character.

Don't use spaces for indentation - use tabs!
4. Comments
4.1 Block Comments
Block comments should usually be avoided. For descriptions use of the /// comments to give C# standard descriptions is recommended. When you wish to use block comments you should use the following style :

/* Line 1 * Line 2 * Line 3 */
As this will set off the block visually from code for the (human) reader. Alternatively you might use this oldfashioned C style for single line comments, even though it is not recommended. In case you use this style, a line break should follow the comment, as it is hard to see code preceeded by comments in the same line:

/* blah blah blah */
Block comments may be useful in rare cases, refer to the TechNote 'The fine Art of Commenting' for an example. Generally block comments are useful for comment