How do you group your class members inside the class? When you add a new method to a class, do you add them to where it should be alphabetically for instance?
Do you use regions? I use them along with the groups created by Visual Studio's interface implementation stub generator, like:
#region IEnumerable
...
#endregion
I use region names like "Properties", etc, but some members prove to be a little more tricky to group/organize.
How do you deal with this?
Maybe this is overly strict, but I'd think that if you have so many class members that you're worried about how to group them to maintain readability, you should probably break your classes up into smaller ones with fewer members.
Besides that, I just use common sense; similar methods or methods that call each other are grouped together, constructors are grouped together, properties are grouped together, public things are on top, things that people are almost never going to need to look at are on bottom.
I personally follow the ordering rules put forth by StyleCop in this. It's very strict on the order of your methods/properties/events/etc.
I don't necessarily believe that it has the "best" rules, but I still follow it, mostly because it's a good tool to guarantee consistency. I'd prefer my code to always be consistent rather than to always fit some ideal that I would dream up - especially since I have multiple programmers, and an external tool helps enforce the rules solution-wide.
Use regions, broken up by functionality. This way, as your class grows, you can see individual regions starting to grow, and then the regions themselves become signposts of what sorts of responsibilities this class is implementing, and guidelines towards refactoring (i.e., "Hey, my 'Process Item' region is like 5 functions! Maybe I need a class to process items!").
Generally:
IEnumerable<T>), but absolutely for explicit interface implementationsIf ASP.NET:
If I have a method that has a few overloads then I add a region for those. Or if there are a few methods that are similar but not necessarily overloads (e.g., Find, FindAll, FindIndex, etc. in List<T> then they'd be in one region of "Find").
The point is to group things off for if I want to find something in the class but not by name. Effectively the regions provide metadata about members of the class that are only good for editing.
That's my general approach to organization, which my regions also follow from. Again: in general. Every class is different (otherwise why write it?) so YMWV: there is no "may" in that.
I don't reorder methods or properties when I add a new because the Visual Studio editor orders them in the object selection drop-down-list. I do group together the methods, properties and class variables in the source. In large classes I've used regions, but for most classes I don't feel they are needed.
Although Pete Brown doesn't address regions, he does offer a helpful list for naming conventions at his site.