Hey #region haters; Why all the fuss?
I hear a lot of programmers saying #regions are a code smell. From programmers I don’t know to celebrity programmers, while the development community appears to be passionately split.*
The haters definitely have a point about it being used to hide ugly code, but when I open a class and see this, it just looks elegant to me.
Elegant Regions
Now none of these regions are hiding thousands of lines of ugly code, actually, most of these regions contain only 3 properties and/or methods and the last curly brace is on line 299. So the whole thing with 17 properties and methods including comments and whitespace is only 300 LOC. … really, how much of a mess could I possibly be hiding?
To me, the only question is whether I should have this functionality in the ContainerPageBase or the MasterPageBase**.
You may also notice the regions I have are not of the Fields / Constructors / Events / Properties / Methods variety. It has taken some time for me to accept that all data members (aka fields) do not need to be at the top of the class as I was classically trained to do and that perhaps grouping them by functionality is a better idea. This philosophy only makes regions that much more valuable.
… is anybody still here? …. have I converted anyone? 😉
* These posts are fairly old, but in my experience in the developer community; the consensus hasn’t changed.
** The Database Connection & Current User regions may have some scratching their heads. There are valid reasons for them, however the Data Connection region will never be included at this level again. More on that in a future post.
Copyright © John MacIntyre 2010, All rights reserved
Senior Software Consultant working in the Toronto area. I specialize in Microsoft technologies and have a long history of taking software development projects from idea, through development and implementation, and years of maintenance.
Always looking for interesting projects. 
John,
I’m assuming you wrote those regions so the classification mechanism makes sense to you, but consider how someone else may classify sections of code and what names they would use.
If I have to find a piece of code in that page I must first classify it according to your scheme and then expand that region to see if I guessed correctly. If I did guess correctly then you saved me scanning a number of lines of code at the expense of having to figure how you classified something, however if I didn’t guess correctly, I now have to re-calculate which region it is in and repeat the process.
Compare this to simply collapsing all methods / properties down to just their signatures, now I can scan a bunch of (hopefully) well named signatures and find exactly what I am looking for with no additional complexity or context switch.
I know which approach I prefer =)
Thanks for the comment Neal,
I did write the regions and the classification mechanism does make total sense to me, but I think I see what you’re getting at. … But if you assume the naming for the regions is unexpected or outside your paradigm, wouldn’t the property and method names be equally flawed? … although I suppose just scrolling through a list of methods, you’d still find it.
Bug I still prefer regions (if used without abuse).
At the risk of getting flamed, I like regions. I agree with Neal in that I think they’re somewhat subjective – however, I disagree with the reason he raises the point.
This is subjective of the same ilk as naming of methods, variables, classes, etc. I’d like to think that if the rest of your code is architecturally sound, then so will your regions.
How do you know which classes to scan? How do you know which folder to look in? It’s all an extension of your programming style.
I use regions, I like them, I’m not as right wing as most of the programming community in that I’m neither passionately for or against them. They’re a tool that can be used or abused… I’ve seen really poor use of them, just as I have seen really poor architecture and development styles. I’ve also seen excellent uses of them.
The only problem I have with regions right now is that I can’t seem to find a shortcut to expand all regions in the currently open document. I know that Ctrl+M+M will open the current region, but when debugging it’s quite irritating to open a class that is completely collapsed to region definitions.
Otherwise, I love the idea of being able to close up code segments that take up a ton of space. WF Dependency Properties, for example.
I believe “Ctrl+M+P” expands all regions and collapsed methods.
I’m actually in the “take it or leave it” camp when it comes to regions. I like them for organizing code into coherent chunks, but unfortunately I see other developers often going in and adding code either outside a region or within a region it doesn’t belong to. A convention for region use is only as good/useful as the developers who’re supposed to use it.
Regions is a good feature to organize and navigate code.
Macro to expand all region (without stopping outline like ctrl+m+p)
DTE.ActiveDocument.Activate()
DTE.SuppressUI = True
DTE.ActiveDocument.Selection().StartOfDocument()
Do While DTE.ActiveDocument.Selection().FindText(“#region”, vsFindOptions.vsFindOptionsMatchInHiddenText)
Loop
DTE.ActiveDocument.Selection().StartOfDocument()
DTE.SuppressUI = False
To collapse all region:
DTE.ActiveDocument.Activate()
DTE.SuppressUI = True
DTE.ActiveDocument.Selection().EndOfDocument()
Do While DTE.ActiveDocument.Selection().FindText(“#region”, vsFindOptions.vsFindOptionsBackwards)
DTE.ExecuteCommand(“Edit.ToggleOutliningExpansion”)
Loop
DTE.SuppressUI = False
DTE.ActiveDocument.Selection().StartOfDocument()
You can bind shortcuts for the macros. (ctrl+m+c to collapse all region, ctrl+m+e to expand all region for example)