JonDJones C Sharp Style Guide

When you have multiple developers working on a project, having a style guide is important to ensure that your source code is written in a consistent manner.  As the old adage goes, developers spend more time reading code than they do writing it.  IMHO making sure your code is easy to read is an essential step to make maintaining the system as easy as possible.  

There are many different ways to structure your code; I have my preferences which some people might agree with, others might not.  The important part is just agreeing on something that works with your team.  Below lists my recommended style guide which I tend to use on projects, you might not like all my ideas so feel free to use the bits that work for you.  The inspiration for these styles comes from a few different sources, Resharper, code complete, refactoring, the clean coder to name a few.

Classes & Class Names

Name written in Pascal case, e.g. MyClass.  Acronyms should be treated as words, e.g. JsonFormatter, rather than JSONFormatter  One class per file. The only reason to use inner classes is to manage global project resources, e.g. static read-only.  Where needed comment should be placed on a separate line.  Ensure there is a space between the comment and the delimiter.

Method Names

Name written in Pascal case, e.g. MyMethod().  Having more than one return statement is acceptable, but, if possible try to keep each method with only one return statement.

Interface Names

Prefixed with an I, e.g. IMyInterface.  Otherwise, written in Pascal case.

Namespaces

Name written in Pascal case, e.g. CompanyName.Website

Fields

All non-static fields should be written in camel case.  My preference is to denote a private field with an underscore. I HATE code that uses this to refer to fields.  Fields should always be declared with access level modifier, e.g. public, private, internal etc... I find this adds extra typing and makes the code harder to read.

private int _privateVariable

Rather than:

private int privateVariable;
this.privateVariable;

All fields should be declared on a new line, e.g.

private int _privateVariableOne, _privateVariableTwo;

Rather than:

private int _privateVariableOne;
private int _privateVariableTwo;

Use 'var' as it makes refactoring a lot simpler.  Do not use the type name within the name, AccountType is good, enumAccountType is bad.

private var _privateVariableOne = 0;

Properties

Name written in Pascal case, e.g. MyProperty { get; set; }

Spacing

Indentation should be done using tabs

Braces

Each brace is placed on a new line.  All if/else only has one line it's acceptable to not use braces in these instances, less code to write is generally easier to maintain e.g.

if (condition)
Line 1
else
Line 1

Otherwise:

if (condition)
{
Line 1
Line 2
}
else
{
Line 1
Line 2
}

Switch Statements

Use the default case to throw an invalidation operation if not required to ensure you spot bugs early.

switch (variable) 
{
    case 1:
        break;
    case 2:
        break;
}

Comments

Comments should be used to describe why the code has been written a certain way.  Comments can easily become obsolete and forgotten, so unless your comment is describing something that the code alone can't explain, don't use them.  Well designed classes and good naming conventions should mean comments aren't needed.

Doc-types

Unless you're writing a public facing API these are the biggest waste of time.  They always become out of date quickly and in 99% of the cases, all they do is mimic the same information as the method signature.  If it doesn't add value, don't do it

Commented Out Code

All code is in source-control.  Old commented out code just adds bloat to your code.  If it's not being used and it's not needed you should delete it.  If a team member disagrees make sure they are happy using source control history.  

Deadspace

Don't allow dead spaces in your source code, as it makes merging harder.  Make sure all developers have a visual studio extension installed to remove dead space automatically.

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

Back to top