Order of items in classes: Fields, Properties, Constructors, Methods

This is an old but still very relevant question, so I'll add this: What's the first thing you look for when you open up a class file that you may or may not have read before? Fields? Properties? I've realized from experience that almost invariably I go hunting for the constructors, because the most basic thing to understand is how this object is constructed.

Therefore, I've started putting constructors first in class files, and the result has been psychologically very positive. The standard recommendation of putting constructors after a bunch of other things feels dissonant.

The upcoming primary constructor feature in C# 6 provides evidence that the natural place for a constructor is at the very top of a class - in fact primary constructors are specified even before the open brace.

It's funny how much of a difference a reordering like this makes. It reminds me of how using statements used to be ordered - with the System namespaces first. Visual Studio's "Organize Usings" command used this order. Now usings are just ordered alphabetically, with no special treatment given to System namespaces. The result just feels simpler and cleaner.

According to the StyleCop Rules Documentation the ordering is as follows.

Within a class, struct or interface: (SA1201 and SA1203)

• Constant Fields
• Fields
• Constructors
• Finalizers (Destructors)
• Delegates
• Events
• Enums
• Interfaces (interface implementations)
• Properties
• Indexers
• Methods
• Structs
• Classes

Within each of these groups order by access: (SA1202)

• public
• internal
• protected internal
• protected
• private

Within each of the access groups, order by static, then non-static: (SA1204)

• static
• non-static

Within each of the static/non-static groups of fields, order by readonly, then non-readonly : (SA1214 and SA1215)

• readonly
• non-readonly

An unrolled list is 130 lines long, so I won't unroll it here. The methods part unrolled is:

• public static methods
• public methods
• internal static methods
• internal methods
• protected internal static methods
• protected internal methods
• protected static methods
• protected methods
• private static methods
• private methods

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.

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

Rather than grouping by visibility or by type of item (field, property, method, etc.), how about grouping by functionality?