Is there a C# official guideline for the order of items in terms of class structure?
Does it go:
I'm curious if there is a hard and fast rule about the order of items? I'm kind of all over the place. I want to stick with a particular standard so I can do it everywhere.
The real problem is my more complex properties end up looking a lot like methods and they feel out of place at the top before the constructor.
Any tips/suggestions?
There certainly is nothing in the language that enforces it in any way. I tend to group things by visibility (public, then protected, then private) and use #regions to group related things functionally, regardless of whether it is a property, method, or whatever. Construction methods (whether actual ctors or static factory functions) are usually right at the top since they are the first thing clients need to know about.
the only coding guidelines I've seen suggested for this is to put fields at the top of the class definition.
i tend to put constructors next.
my general comment would be that you should stick to one class per file and if the class is big enough that the organization of properties versus methods is a big concern, how big is the class and should you be refactoring it anyway? does it represent multiple concerns?
The closest you're likely to find is "Design Guidelines, Managed code and the .NET Framework" (http://blogs.msdn.com/brada/articles/361363.aspx) by Brad Abrams
Many standards are outlined here. The relevant section is 2.8 I think.
I don't know about a language or industry standard, but I tend to put things in this order with each section wrapped in a #region:
using Statements
Namespace
Class
Private members
Public properties
Constructors
Public methods
Private methods
I would recommend using the coding standards from IDesign or the ones listed on Brad Abram's website. Those are the best two that I have found.
Brad would say...
Classes member should be alphabetized, and grouped into sections (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types)
Rather than grouping by visibility or by type of item (field, property, method, etc.), how about grouping by functionality?
From StyleCop
private fields, public fields, constructors, properties, public methods, private methods
As StyleCop is part of the MS build process you could view that as a de facto standard
As mentioned before there is nothing in the C# language that dictates the layout, I personally use regions, and I do something like this for an average class.
public class myClass
{
#region Private Members
#endregion
#region Public Properties
#endregion
#region Constructors
#endregion
#region Public Methods
#endregion
}
It makes sense to me anyway
I prefer to put the private fields up at the top along with the constructor(s), then put the public interface bits after that, then the private interface bits.
Also, if your class definition is long enough for the ordering of items to matter much, that's probably a code smell indicating your class is too bulky and complex and you should refactor.
Usually I try to follow the next pattern:
Each part (static and instance) consists of the following member types:
Then the members are sorted by visibility (from less to more visible):
The order is not a dogma: simple classes are easier to read, however, more complex classes need context-specific grouping.
I keep it as simple as possible (for me at least)
Enumerations
Declarations
Constructors
Overrides
Methods
Properties
Event Handler
Order things where they feel clean to you and whoever maintains the code. Everyone usually has some degree of personal preference.
I don't think it's necessary to force a particular style or ordering into a class.
According to the StyleCop 4.3 Rules Documentation (available from the StyleCop 4.3 download page) the ordering is as follows.
Within a class, struct or interface: (SA1201 and SA1203)
Within each of these groups order by access: (SA1202)
Within each of the access groups, order by static, then non-static: (SA1204)
An unrolled list is 130 lines long, so I won't unroll it here. The methods part unrolled is:
The documentation notes that if the prescribed order isn't suitable --- say, multiple interfaces are being implemented, and the interface methods and properties should be grouped together --- then use a partial class to group the related methods and properties together.