Take the 2-minute tour ×

What coding standards do you think are important for .NET / C# projects? This could be anything from dealing with curly braces and spacing and pedantry like that. Or it could be more fundamental questions such as what namespaces in the .NET Framework to avoid, best practices with config files, etc.

Try to avoid creating a post that is simply the corollary to another. For example, it would be fine to have one post focusing on curly braces. We don't need two to support one style vs. the other. The idea is not to vote for your pet standard, but rather to flesh out what should be thought about when creating standards.


locked by World Engineer Jul 23 '13 at 1:41


closed as not constructive by gnat, Dan Pichelman, GlenH7, MichaelT, Martijn Pieters Jun 16 '13 at 9:51


11 Answers 11

up vote 29 down vote accepted

Here is the official Microsoft Guide on coding standards for the .NET framework Version 4.0.

If you want the older version for 1.1, try here.

I don't necessarily follow this to a 'T', as they say. However, when in doubt, this is the best place to start to be consistent with the current .NET framework, which makes it easier on everyone, no matter if they're new to your particular project or not.

Yup - can't go wrong matching what the people who build the software use. I have seen some religious wars over this sort of thing but when you're handed something that will allow your own code to be consistent with the frameworks that it is using you would have to have an extremely strong argument to not use it. As a bonus, the static analysis tools that MS produces are already tuned to look for these practices. –  Todd Williamson Sep 27 '10 at 19:32
Can I get some feedback on the downvote, please? –  Ryan Hayes Sep 28 '10 at 16:45
What don't you follow? –  JeffO Apr 19 '11 at 11:41
Well, there's a lot of stuff in there and I haven't memorized it yet. So, instead of saying I follow it exactly (which I don't know that I do, so it may or may not be true), I just say I don't, haha. If I knew the whole thing I probably would. –  Ryan Hayes Apr 19 '11 at 12:41

Might want to take a look at StyleCop. You can even incorporate it into some build systems so that style errors will break the build. The default settings are mostly congruent with what MS suggests for guidelines (as posted by others).

You can also alter the rules that it comes with at default.

+1 For Stylecop, I use this and enjoy it –  PSU_Kardi Sep 28 '10 at 19:50

Guidelines from Microsoft:


We adopted this in our office. It's written by Lance Hunt, and it's fairly comprehensive:


It's also brief when compared to framework design guidelines. The bulk of what you need can be printed on 2 pages. This is my preference. –  Brook Apr 19 '11 at 12:31

Start with FxCop. It will tell you about best practices violations in your existing code.

FxCop looks at binaries, it won't tell you about coding style, but it will spot some issues. –  Steve Haigh Apr 19 '11 at 11:42

I try to pick a common set of styles from various sources. Some that were not mentioned before:


I have to recommend the standards made available by SSW (an Australian Consulting company).

Not just coding, but Project Management etc... An incredibly valuable resource.



Methods should be short

Most methods should use most fields in a class.

Choose your names well.

E.g read the Clean Code book


I'm using the following applications to maintain a coding standard besides camelback rules, method name and etc.

GhostDoc - Adds a auto-generated comment on the top each method. The application provides good inital summary of method. (free)


Resharper- code analysis and refactoring http://www.jetbrains.com/resharper/

StyleCop - As a final clean-up before i check-in to TFS. (free)



I hate established coding standards, they're all concerned with either telling you not to make a few silly mistakes, or telling you how to format your code in some way or another. All of which are trivialities.

I mean, they will tell you how many spaces to put between operators, how to case your variables, what 'hungarian-style' prefixes to use (eg _ for members), conflicting advice (eg you cannot call a class Cxyz but you must call an interface Ixyz), how to layout your code (put your variable at the top of the class or at the bottom)

All are useless in the big picture.

What matters to write effective, maintainable and readable code is never mentioned in these standards.

For example: do you put your variables at the top or the bottom of your class? Well, who cares - what does matter is if you group your variables together by functional area. That matters (you'll know this if you've ever seen 20 variables scattered about the place).

They tell you to put your curly brackets in certain places. Big deal! I can read code in both K&R and ANSI style bracketing, it doesn't matter. What does matter is if all Window classes are differentiated somehow (like being suffixed with Form or Dlg or whatever) so you can see which files contain window code and which are ordinary objects.

Stuff like this matters far more than the minor points that standards usually contain. I don't know why they developed like this, but often they're just a ton of rules that get in the way of effective, productive coding.

My standards try to focus more on organisation of code and files. We have certain standards that refer to where files will be found. For example, for the non-dev guys can look at one of our projects and immediately pick up the documentation files they need. Similarly, we try to layout the project code in as similar a manner to other projects as practical (note: as practical, not in a heavily-proscribed manner that may not be appropriate all the time) and basically we try to make standards guidelines that can be modified as needed.

In short - they're there to help us work together, not as a set of restrictive rules that always have to be followed.


Warning: Pragmatism below - The question seems to be worded to elicit debate about the "proper" curly brace style, etc. I don't put up with wasting time on that nonsense.

  1. Install ReSharper, leave the defaults, do whatever it says.

  2. Profit - Everyone on your team will have the same style which will be damn close to the Microsoft guidelines, only deviating on a few points where Resharper standards reflect what is actually more widely-used in industry and are (arguably) improvements .

The less time your team spends creating and referencing some humongous document or book, or dickering about the curly braces and other inanities, the more coding they will get done. ReSharper will enforce naming and style as they type. Done. End-of-debate. Nothing left to argue about. Moving on.

That said, a read of the classic Code Complete, will help them understand the rationale behind coding standards, and offer many great pointers on effectively conveying meaning through the code - something a standards document or inspection program cannot do.

If you want to step-up what resharper can do for you, add StyleCop with the StyleCop for ReSharper plug-in. As mentioned there will be a few minor conflicts between the MS guidelines and the ReSharper defaults. I would just go with ReSharper on those. But whichever side you take just save the results to the ReSharper config file, share it across your team and be done.

(No, I'm not a paid shill for ReSharper, just a happy customer. In addition to its many other features, it handles basic style issues more cost effectively than any standards document or code review system - leaving the brainpower for things that matter.)

