Derik Whittaker

it seems the developer thinks that only regions can be collapsed

2 things

1) If you're gonna use regions, you better make sure your team has a standard on them.  I can't stand seeing different classes using a different structure

2) Keep them generic in nature.  Instead of lets say naming a region for example "Code to Bind Product GridView"...just name it "Binding Methods" or something

3) I agree, too many, just makes it more confusing.  Since this is OOP, regions can be divided based on areas such as Properties, Page Functions, etc.  Keep it simple such as "Constructors", "Utility Methods" etc. and use OOP terminology, not custom termonology

Amazing, I've never seen something so stupidly coded:

#region private bool MethodThatDoesSomething

private bool MethodThatDoesSomething(){}

#endregion

that's just like creating a method that only does one thing, calls another method which is just dumb.  Obviously whoever did that don't know how to code in the first place.  Sad but just stating a truth.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

If separation of concerns is properly applied types in .NET are relatively speaking with small number of members/lines, so the value of regions is disputable in my opinion

I am using them ocassionally only to "group" (read hide) a bunch of helper private methods which were result of "Extract method" decomposing of complex methods.

Summarized: IMHO, one should avoid using regions and if using them at all, he should use them to hide code noise