What should be included in a C# Programming Standard?

Question

I've been tasked to write our department's C# Programming Standard (including guidelines). What sort of standards/guidelines should I include? I've already taken bits from various standards around the net (and pieces from Code Complete), but I'd like hear from developers in the field.

I've already got: Naming Conventions - General/Variables/Classes/Methods/Interfaces/Controls

General Programming Practices - Documentation (comments etc), [WIP]

OO Programming Practices - Encapsulation, [WIP]

What else would be useful? What shouldn't I include?

Answer 1

Have you already suggested that everyone reads the "Design Guidelines for Class Library Developers"? That covers the bulk of it. Other than that, I'd want to hammer home:

• You should very rarely be creating your own structs. Don't think of them as lightweight classes.
• Structs should never be mutable.
• Fields should always be private, apart from readonly fields where the type of the field is immutable
• Only attempt lock-free programming if you're sure that a simpler solution will be too slow - and have evidence!
• Readability is king
• Be aware of cultural issues - in particular, read Microsoft's String Handling Recommendations

I'll add more as I think of them...

Answer 2

Information on how to handle namespaces, assembly/project/solution naming conventions, nameing conventions of files.. grouping of items (for example of your have both Item and Item do they go in the same file?)

• File name guidelines
• Namespace naming / organising guidelines
• Design & architectural guidelines such as using interfaces to create louse coupeling and to make unittesting eaiser (for such as dependency injection and mocking)
• Advice on when things should be refactored (long methods and so on)
• Naming and casing for parameters
• Guidelines on unit testing (if you use it) and on mocking
• Grouping of items (for example of your have both a generic and non-generic implementation of a class do they go in the same file or seperate files following a naming convention?)
• How to handle 3rd party dependencies
• Promoting the use of tools like FxCop, StyleCop and other metrics

Just a couple of things from the top of my head

Answer 3

Guides on maximum method length, maximum class size and maximum loc in a source file are usefull.

Furthermore you can set some guidelines on indentation and code layout and stuff but I found it easier just to do this with settings in Visual Studio and then have your developers import the same settings file for this. This way people don't have to think about this and visual studio does the work for them.

Best practices can be checked automatically too by FXCop and tools like that. So it's usefull to distribute guidelines about that by just making FXCop files available that check all the rules you care about. Dont introduce big FXCop checks in a large existing code-base though try to ramp up the checks over a period of time so people dont get hit with 1000's of FXCop errors

In short:

Try to keep the guidelines short, only include things that are really important. Make them easy to read (you can write naming conventions as an example-class for example where you highlight all the rules with some extra boxes with text) And use tools to automate checks where you can so developers get easy and early feedback.