This post originated from an RSS feed registered with .NET Buzz by Jeff Key. Original Post: C# coding standards Feed Title: Jeff Key Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/jkey/Rss.aspx Feed Description: Topics revolve around .NET and the Windows platform. Latest .NET Buzz Posts Latest .NET Buzz Posts by Jeff Key Latest Posts From Jeff Key

While reading some blogs today, I ran across a nice C# coding standards document.  The document closely follows Microsoft's “Design Guidelines for Class Library Developers” and is very similar to my personal standards.  My notes, as well as some additional standards I try to follow, are below:

3.2.2
I prefer to prefix private fields with an underscore.

5.2.6
Not necessary.  The runtime knows when objects are no longer used, even within the body of a method.  For example:

1 MyObject o = new MyObject();
2 o.DoSomething();
3 DoSomethingElse();

If a GC occurs at line three, the object referenced by "o" may be garbage collected.  (Note that this does not apply when a debugger is attached to the process.)

7.2.1
Classes with internal accessibility don't need to follow this, as versioning is not an issue.  All consumers of objects of that type are compiled with the class.

10.2.6
StringBuilder is not a panacea.  See http://weblogs.asp.net/ricom/posts/43628.aspx and http://weblogs.asp.net/ricom/posts/40778.aspx for appropriate usage.

11.2.2
I prefer to have all of the fields at the top of a class in order of accessibility from public to private.

Personal:
- For methods that return arrays, always return an array.  If the method produces no results, return an empty array instead of null.  If you must return null, note this in the XML documentation.

- Use explicit interface implementation for code that does not adhere to the roll of the object, ie. debug code.  For example, sometimes it's helpful while debugging to get a certain value from each object in a custom collection.  A GetProductIDs method can be written to obtain these values, but the method has no practical use to the consumer and, since it's debug code, it may be changed or removed in the future.  It also pollutes the public interface.  Classes that contain methods like these should implement an I<ClassName>Debug interface and implement those members with explicit interface implementation.

- Provide as much information as possible in exceptions, including how to possibly avoid the exception in the future.  Provide state information, if possible.  For example, if a ProcessInvoice method encounters a line item without an ID, include the name of the product in the error message or in a property off of the custom exception.  This can make debugging much easier for the consumer.

- Never store the integral value of an enum between application sessions.  Members of the enum may be removed or reordered.