I wrote a follow up here about it:
http://www.stormbase.net/region-hate

For around 5 years I used to enjoy meticulously organising every code file into regions. Even my elborate report methods had regions for “create report”, “create headings”, “create totals” etc.

Then I saw the light…

These days, there is no greater irritant to me than opening a fellow developers code file and see a closed bunch of regions.

I believe that any code group not visible in one screen is generally bad design.

When all my properties, constructors and methods collapsed, is not visible on one page – likely my class is doing more than one thing.

If my method’s longer than 10-15 lines of code, it’s 99% of the time bad design. Time to freshen it up!

There are exceptions to every rule, but the last time I used a region was for a very bad 100 option switch statement. A delegate dictionary built from an embedded resource text file sorted that one into very elegant code.

There is always a solution to keep code short and simple, without resorting to regions.

This article is somewhat asinine.

First of all, regions are not despicable because they group code only along one dimension – all of our structures do this. You can put your properties into business-related objects (car, plane) and might thereby lose the grouping by subsystem (images, sounds) or you group them into subsystem objects and thereby lose the connection to business objects.

I would like to remind some of the commenters here that OOP is not only about tearing code apart into tiny rags, but also about grouping things. At some point, you’ll have to connect different parts of your code and 100 classes with two methods each are simply not any better than two classes with 100 methods each. You could even argue that while an oversized class at least gives you a list of all methods you can search through, you are absolutely at a loss once you have to navigate through an unknown 10-leveled object hierarchy because everything had to be broken down into tiniest bits.

The goal should always be a fair balance between modularity and maintaining the class landscape in a way that other developers can still grasp it without memorizing hundreds of interconnected classes. This means, the size and the complexity of the resulting modules always has to be considered, too. Take, for example, the code snippet provided above by Blub:

#region rendering stuff
private void RenderX()
{…}
public void RenderY()
{…}
#endregion
#region sound stuff
private void PlaySoundX()
{…}
public void PlaySoundY()
{…}
#endregion

He or she claims that this is bad code and must be refactored. I tend to disagree. Without knowing what the rest of the class as well as the implementations of these methods look like, I can imagine situations both where a refactoring is badly needed as well as where a refactoring would not be any helpful.
The need or willingness to categorize need not even mean many lines of code. 30 lines can perfectly contain six methods which logically belong directly to the containing class, yet which for another reason – “along another dimension” – can be categorized into two groups.
I would like to ask the author of the comment for a more complete example here.

It has been frequently mentioned that if a class gets too long, it should be broken down into several pieces. Truly, often there is no choice about the length. Once you implement a somewhat bigger interface such as System.Collections.Generic.IList, your class will inevitably have many methods. If you only offer read-only access, half of them will only throw NotSupportedExceptions, so these methods are not needed, but have to be there. While this may still be attributed to bad design of the System.Collections.Generic namespace, where interfaces such as IList should inherit from others that only feature the respective read-only members, you again get many methods once you implement IList more than once (for different Ts).
For your information, I do consider it definitely good practice to add as much support for standard interfaces, wherever possible.

One last issue I found somewhat funny in the above comments is when some commenters stated that “regions are bad because you can do the same thing with partial classes”. If you condemn regions for their capabilities of hiding (too) large blocks of code and leading to huge classes, wouldn’t partial classes be even worse? Not only do they put the “hidden” code completely out of sight of the programmer – as opposed to regions, which are still in the same file (and editor tab) -, they even lead to the creation of seemingly well-structured units (a collection of similarly-sized files) at design time, yet the compiled result will be a huge class again.
In fact, partial classes are just another organizational level which has no further significance for the compiler, right above the region level.

As a conclusion, while regions can of course be misused – as about any other language feature -, I cannot agree with the statement that they are generally the reason or a signal for bad code.

Sub ClearRegions()
DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
DTE.Find.FindWhat = “^:b*\#region.*\n”
DTE.Find.ReplaceWith = “”
DTE.Find.Target = vsFindTarget.vsFindTargetCurrentDocument
DTE.Find.MatchCase = False
DTE.Find.MatchWholeWord = False
DTE.Find.MatchInHiddenText = True
DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxRegExpr
DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone
DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
DTE.Find.Execute()

DTE.Find.FindWhat = “^:b*\#end region.*\n”
DTE.Find.ReplaceWith = “”
DTE.Find.Target = vsFindTarget.vsFindTargetCurrentDocument
DTE.Find.MatchCase = False
DTE.Find.MatchWholeWord = False
DTE.Find.MatchInHiddenText = True
DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxRegExpr
DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone
DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
DTE.Find.Execute()
End Sub