Semantic #region usage

What's your opinion about using #region folding using application semantic, instead of folding for "syntax".

For example:

#region Applicati开发者_运维知识库on Loop
#region User Management
#region This Kinf of stuffs

instead of

#region Private Routines
#region Public Properties
#region ThisRoutine // (Yes, I've seen this also!)

In this logic, I'm starting fold even routine bodies. I'm starting to love #region directive (even using #pragma region when using C++!).

That would suggest you're doing too much in one type - why would an "application loop" be in the same type as "user management"? If you find yourself wanting to do this, consider splitting the functionality into different types.

Typically I use regions for interface implementations, Equals/GetHashCode overrides, and operators - but that's usually all.

The only time I use a region is to hide something like a bunch of non-implemented interface methods or a bunch of code which is for the chop but I'm not quite ready to kill it.

I tend to think if it needs folding to help you keep track of it all there is too much code in the file (or maybe another general code smell [or is the folding the smell?]) and if it doesn't need folding the only thing folding will achieve is frustrating people who have to go looking for code which should be on display.

I'm not a fan of hiding code from myself.

I prefer dividing my code into regions based on syntax, because I can easily find the constructor, overridden methods and so on...

I use regions to group methods with a common/related purpose.

So, rather than public, protected, private regions, think of "Initialisation", "Load and save", "Event handlers", etc.

The purpose of this is for the folded class to act as a summary or overview of the functionality, and make it easy to find the parts you are looking for. Ideally, you will generally settle on a few standard region "types" that you use throughout your application's classes so that they are all consistently subdivided.

I've seen developers who do this in the past and the end result is rarely good. The problem is with the expectation that those who follow will understand the groupings and correctly identify the correct region for their additions. In my experience what tends to happen is that, at best, one ends up with a proliferation of new regions, one per each functional change and, at worst, new methods junked in any old place or regionless at the end of the class.

I'd say go with a scheme that is obvious. The most common is the 'Private Fields/ Public Fields / Private Properties / Private Methods / Public Properties / Public Methods' scheme. (Personally I favour grouping by visibility: 'Public / Internal / Private' with the more visible members at the top as that is what a casual visitor to a class is going to be interested in first and what goes where is still blindingly obvious.)