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.


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


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.

Rather than:

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

Rather than:

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


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


Indentation should be done using tabs


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.


Switch Statements

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


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.


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.  


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.