What's the best way to layout a C# class?

Question

Is there a standard way of laying out a C# file? As in, Fields, then Properties, then Constructors, etc?

Here's what I normally do, but I'm wondering if there's a standard way?

1. Nested Classes or Enums
2. Fields
3. Properties
4. Events
5. Constructors
6. Public Methods
7. Private Methods

Do people group their fields together, or do they put them with the properties? Or do people not worry about an order? Visual Studio seems to make it so hard to do.

Edit: Moved other part about ReSharper here: Make Resharper respect your preference for code order.

Answer 1

I think there's no best way. There are two important things to consider when it comes to layout. The first most important thing is consistency. Pick an approach and make sure that the entire team agrees and applies the layout. Secondly, if your class gets big enough that you are searching for where those pesky properties live (or have to implement regions to make them easier to find), then your class is probably too large. Consider sniffing it, and refactoring based on what you smell.

To answer the reshaper question, check under Type Members Layout in Options (under the C# node). It's not simple, but it is possible to change the layout order.

Answer 2

I tend to clump private data and tend to clump related methods/properties in functional groups.

public class Whatever {
   // private data here
   int _someVal = kSomeConstant;

   // constructor(s)
   public Whatever() { }

#region FabulousTrick  // sometimes regionize it
   // fabulous trick code
   private int SupportMethodOne() { }
   private double SupportMethodTwo() { }
   public void PerformFabulousTrick(Dog spot) {
       int herrings = SupportMethodOne();
       double pieces = SupportMethodTwo();
       // etc
   }
#endregion FabulousTrick
   // etc
}

Answer 3

Whatever makes your more productive. Some like private fields next to property accessors, some like fields together above the constructors. The biggest thing that can help is grouping "like," elements. I personally like bringing together private methods, private properties, etc.

Try some things out and again, whatever you feel makes you more productive and helps you keep your code maintained.

Answer 4

I don't believe regions are necessarily a sign of bad code. But to determine that you will have to review what you have. As I've stated here this is how I regionize my code.

Enumerations
Declarations
Constructors
Methods
Event Handlers
Properties

But the main thing is keeping it consistent and purposeful.

Answer 5

Each to their own, but I tend to follow the same order that the MSDN help follows.

I also don't like to nest classes or enums, instead create separate files for them, that also makes writing unit tests easier (since it's easy to find the associated test file when you need to add/fix/refactor a test).

IMHO the order isn't that important because VS makes it very easy to find all members (especially if you follow the one class/interface/enum per file approach), and Sandcastle will group them if you want to build docs, so I'd be more concerned about giving them meaningful names.

Answer 6

I tend to use Microsoft StyleCop, which has a set order according to rule 1201:

Cause An element within a C# code file is out of order in relation to the other elements in the code.

Rule Description A violation of this rule occurs when the code elements within a file do not follow a standard ordering scheme.

To comply with this rule, elements at the file root level or within a namespace must be positioned in the following order:

Extern Alias Directives

Using Directives

Namespaces

Delegates

Enums

Interfaces

Structs

Classes

Within a class, struct, or interface, elements must be positioned in the following order:

Fields

Constructors

Finalizers (Destructors)

Delegates

Events

Enums

Interfaces

Properties

Indexers

Methods

Structs

Classes

Complying with a standard ordering scheme based on element type can increase the readability and maintainability of the file and encourage code reuse.

When implementing an interface, it is sometimes desirable to group all members of the interface next to one another. This will sometimes require violating this rule, if the interface contains elements of different types. This problem can be solved through the use of partial classes.

1. Add the partial attribute to the class, if the class is not already partial.

2. Add a second partial class with the same name. It is possible to place this in the same file, just below the original class, or within a second file.

3. Move the interface inheritance and all members of the interface implementation to the second part of the class.

Answer 7

On top of keeping a consistent set of regions in your class files, I keep all components of a region in alphabetical order. I tend to have a bit of "visual memory" when it comes to reading code and it drives me crazy having to use the navigation dropdown to find code in a file because it's all over the place.

Answer 8

I use the following layout:

events globals/class-wide fields private/internal properties methods public/protected properties methods nested classes (although I try to avoid these whenever possible)

I also firmly believe in 1 code "thing" (class, interface, or enum) per file, with the file name the same as the "thing" name. Yes, it makes a larger project but it makes it infinately easier to find things.

Answer 9

You can try Regionerate to help with this. I really like it and it's a Scott Hanselman pick.