View on GitHub


C# Coding Guidelines

Download this project as a .zip file Download this project as a tar.gz file

C# Coding Guidelines

This is a set of C# Coding Guidelines I'm putting together for myself and others in the community who would like to contribute. It will be both coding guidelines and tips / best practices for C#.

I have also added some snippets to load into Visual Studio for time saving purposes.

Feel free to contribute!

Code Layout

Use Visual Studio Defaults

Source Code Layout


int price;
int tax;
int total;


int price, tax, total;


public int returnInt()
    // stuff


public int returnInt(){
    // stuff


use camel case for fields and local variables:

string myString

Use Pascal casing for all public member, type, and namespace names consisting of multiple words.

(From MSDN)

public class SampleClass
   public Color BackColor 
      // Code for Get and Set accessors goes here.

Use camel casing for parameters:

public void RemoveString(string ourString) 

DO NOT use Hungarian notation or language specific naming ( IntMyInteger or ConvertToShort )


A class or interface should have a single purpose.

A class can represent a primitive type or datastructure, abstraction or handle interaction between other classes. But don't mix any of these things. Follow the "Single Responsibility Principle" (from SOLID)

Use design patterns to communicate the intent of the class.


Constructors should only be used to create a useful object. If you have too many paramaters in your constructor your class may have too much responsibility.

Use a method instead of a property

Whenever you have a property that:

Use a method instead.

Use Pascal casing


Throw exceptions not values

It's common for people throw a status value, such as a plain text friendly message or a boolean value to indicate success. Use the exception system to it's advantage. Catch the exception and out output it to a debug console or log it in another way. It's ok to append a friendly message or hint to what may have happened, but don't rely on this. Structured exception handling reduces debugging and repair time dramatically.