views:

170

answers:

8

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?

+3  A: 

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...

Paddy
+6  A: 

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...

CSharpAtl
Agreed, the only "point" to having any sort of logical organization is for your own (and other developers) benefit to be able to find things later when you need to go back. Use whatever feels good and looks right to you.
BBlake
#region should be used sparingly; they hide code and often add little or no value; http://www.codinghorror.com/blog/archives/001147.html
g .
+3  A: 

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.

Bob
+4  A: 

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.

BobbyShaftoe
+3  A: 

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.

Stefan Steinegger
+2  A: 

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.

Ray
+3  A: 

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.

Philip Wallace
+3  A: 

Whatever StyleCop tells me to. :)

Chris