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. Ensuring that your code is easy to read is an essential step towards making system maintenance as easy as possible.

Obviously, there are many different ways to structure your code and many different rules and patterns that you can adopt. I have my preferences. Some people might agree with these preferences, others might not. The important part of defining a coding standard is defining a common set of rules that works with your team. People need to know the expectation of how they should write code, otherwise, arguments and frustrations will entail. Below lists my personal recommended style guide that I apply to all projects that I oversee. 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, tools like Resharper, and Books like Code Complete, Refactoring, and The Clean Coder to name a few.

Classes & Class Names

  • Class names are written in Pascal case, e.g. MyClass
  • Acronyms should be treated as written as whole words, e.g. JsonFormatter, rather than JSFormatter
  • One class per file. The only reason to use inner classes is to manage global project resources, e.g. static read-only.
  • Comments 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 in a method is acceptable, however, 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.  
  • 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...
  • Avoid _ to reference private variables
  • All fields should be declared on a new line, e.g.

Rather than:

  • Use var to declare variables 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
  • Do not commit code with white space. use a tool to auto-remove it


  • Each brace is placed on a new line.  
  • If an if/else is written on one line, it's acceptable to not use braces in these instances. Less code is 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. Use swagger instead.

Commented Out Code

Do not check in commented out code just in case it is needed later. 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.  The code will still be in 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.

That concludes my rules. Happy Coding 🤘