In what order should I place properties, events, functions, function overrides, etc. in C# classes? [duplicate]

Question

This question already has an answer here:

• Order of items in classes: Fields, Properties, Constructors, Methods 15 answers

When creating a new C# class I am not certain of what the best logical order for declaring properties, event delegates, functions, function overrides, etc. are and what considerations should be taken into account when deciding on that order.

Typically when creating the code behind class of a WebUserControl I end up placing things in this order:

1. Events
2. Properties
3. Life Cycle Event override functions
4. Other functions

Is there a more logical way to do this and what considerations should I be making when deciding on how to order these elements of the class within the class file?

Answer 1

This is a style preference. A lot of people do:

1. Properties
2. Overrides
3. Other functions
4. Events

Some people also separate each using #regions.

Answer 2

Does not make any difference to the compilation, you might want to wrap the sections in #region to make it easier for someone reading your code to know where they are and keeping them organized. It probably should be a coding standard for your company so all code is organized similarly and is less frustrating to look at...

Answer 3

Whatever StyleCop tells me to. :)

Answer 4

Just go with whatever makes sense to you, or is in your coding standards. As long as it's consistent, it doesn't really matter...

Answer 5

I don't think the order is important as long as you are consistent with your style. Consider the use of regions, but don't go overboard with them. As a general rule of thumb for me, I avoid all nested regions. That is just too much code hiding.

Answer 6

Consistency is more important as a certain order.

Personally, I like to find members quickly by visibility:

• public
• protected
• private

As a user of the class you usually just need the public interface, if you derive, you need also the protected interface, only if you are changing the class itself you need to look at the private stuff.

Answer 7

As long as you have a standard style throughout your development team, it is whatever works for you. If you are using Visual Studio, then with the class viewer and member drop down menu, it becomes even more irrelevant. Check out the Regionerate addin - it gives you the options to sort members by type or alphabetically and also add regions by type, visibility etc. If not of the default settings suit you, you can define your own.

Answer 8

I usually put member declarations at the top, then methods (life-cycle and others), then event handlers, and finally properties. For methods, I try to order them roughly in the order they will be called. For example. the methods called when loading a page come first, then the ones called when saving a page submission. Properties and event handlers are at the end because they are generally trivial, so I put them out of the way.