I also disagree with the article.
With great power comes great responsibility. Like any language feature that can be misused (partial classes, delegates), some common sense needs to be applied. If a developer hasnât the sense to see that overuse of such a feature will cause readability maintenance issues then youâve got bigger problems within your team than you originally thought.
In defense of regions, when you are doing code reviews or presentations, I find it helpful to use regions to focus your audienceâs attention on one set of code at a time.
On CodeProject there is a set of macros that automatically adds regions and comments around procedures (ctrl-d), and opens/collapses all regions (ctrl-shift - / +). Itâs one easy route to go if you like regions as I do.
(Alt-ctrl-j) in R# is an awesome way to add regions as wellâŚ
I donât think itâs a code smell, because regions are soooo easily opened through VS or macros⌠And you are using resharper to develop right? Itâs really a crime not to, as those light bulbs R# provides can really be helpful for tightening code (and regions certainly doesnât hide those errors or suggestions - though a pragma will).
Just my $0.02,
Wow. The asininity of some of these comments is astounding. Code folding hides things and groups things, yes, BUT THATâS WHAT CLASSES ARE FOR. What Jeff is saying is that if your classes are so long that you need to fold them, YOU SHOULD REFACTOR THEM TO BE SMALLER. Need to group business logic? Pull that shit out into a separate class. Thatâs what I meant by code smell - if youâre tempted to use #regions, consider whether you should be creating a new class.
I understand that sometimes youâre stuck with legacy code, but try to take some time to refactor that shit first, if at all possible. At the very least, put your new logic in a new class and call it from the old code. Anything else just exacerbates the problem.
I disagree. I think the author was using regions for the wrong reasons. On a scenario where multiple guys are working on the same file , this is a perfect way to ring fence your code. Working with just your region code expanded gives you the feel of working on a small chunk of code and savesyou from un necessary scrolling/searches.
@post :
I strongly disagree. The ability to hide regions of code in order to underline others is a good thing. And Visual Studio can be configured to show them open by default AFAIK.
Two points. The argument that regions are all most developers will ever see because itâs the default seems nuts to me. It seems utterly reasonable to expect a professional coder to set the preferences of Visual Studio. They are programmers. Itâs one thing to expect non-technical users to accept program defaults because they donât know enough to go set preferences. Thatâs a poor excuse when it comes to professional programmers. Secondly, regions are not code written to accomodate the editor; theyâre written to accomodate the coder. Overall, this seems like a fairly shallow complaint. Set your editor the way you want things to look and get over what other people prefer in their editors.
Sometimes I am forced to work in Centura/SQLWindows. I am told it was popular outside the states sometime in the 90âs.
By default everything is folded and I mean everything. Every if, for, else, function, variable blocks⌠That and the editor is not very discoverable, so while there probably is a un-colapse all hotkey I havenât found it yet.
It can be the most annoying feature ever if not implemented properly.
On the other hand, Netbeans collapses my code in a lot more friendly manner and finding the collapse all un-collapse all hotkeys was discoverable from the menu.
Emacs is getting a lot of attention in this post. I think itâs
because it was the first IDE (or one of the first),
It isnât just that. Emacs over the years has had support added for pretty much every text editing need a person could possibly have. Thatâs a lot of functionality.
Nobody who sets out to create an editor from scratch (not even Microsoft) can possibly produce all that functionality when they are done. So the absolute best any other editor can shoot for is implementing a subset of Emacs. Some parts of that subset they may manage to implement a bit better, but it will still just be a subset.
Its true that occasionally these alternate editors do something new. However, any new functionality someone may come up with can just as easily be added to Emacs. If its useful, it will be done by someone. If its really useful, it will get moved into the default codebase.
So thereâs really not much point in anyone ever creating their own editor. Iâm not upset that some people still have the hubris to do it, as the competition ends up making Emacs better. But thatâs all it is doing.
Your project is now full of crappy code that you canât see
I want to have this framed and put on the wall at work 
Will you settle for a motivational poster: http://img184.imageshack.us/img184/8929/72ve0ptu4iry6.jpg
wtf. i thought it was standard behavior to fold code automatically. #regions seem to be some ugly hack. indentation and curly braces should give editor enough hinting to fold if requested by user. donât see how it fits to teamwork, as it should be editor-side feature only. if i recall correctly, even vim handles code folding quite sanely, without any special #regions or other crap. code folding also allows you to have clear overview of a class or other code.
The underlying problem with using #region for anything other than what it was designed for (hiding auto-generated boilerplate) is that it is not in any way understood or checked by the compiler.
So whatever scheme you have canât ever be relied upon when you actually need to read the code to find a bug, drill down on one particular area. Put your public methods in the âprivate regionâ, your event handlers in the stubs region, the compiler wonât care. Put your âcustomer99-specificâ code in a function or class, and you can be sure a change to it does not change the behaviour for customer-74. A region, all bets are off.
If your code is bug-free and perfect this is not a problem. But the more âreal-worldâ, pragmatic, rushed and buggy your code is, the bigger a problem you have.
Jeff, yes!!! vim probably other editors too have very very advanced folding / marking / navigating features. That stuff in your post is rediculous.
for vim you have folding by complex expression based on the language, by indent, by other things, and those expressions are already made for basically every programming language out there, no one should be manually marking fold locations in code.
Agreed. Regions are not anything Iâve personally found interesting or useful. Iâm constantly stripping them out of generated code.
Visual Studio does automatically fold pieces of code. Functions and block level.
Regions just allow you to declare custom fold points with names.
So please people, donât think Visual Studio doesnât do other code folding that doesnât require Regions, because it does.
I do not agree. I see your points, and I acknowledge them, but my personal experience is that folding (with vim) improves my productivity.
Indeed, I take care of adding folding tags as much as I can, because I prefer to keep control of the folding level. I do not like having to unfold every indentation, that makes code navigation very hard. I do like having folding at the routine level. It makes my navigation and my cut-and-paste very easy. If I want to delve into the details of a routine, then I unfold it with a single hit of spacebar.
I think itâs a matter of taste, but to me, folding increases productivity so much that I install vim 7, if I donât find it on the system, just for folding.
@Keith try something like:
#region Private Methods
public WtfEnum AreRegionsBad()
{
WtfEnum result = WtfEnum .No;
switch (coderType)
{
case SensiblePro:
result WtfEnum.No;
break;
case Hacker:
#region nasty
result = WtfEnum .Yes;
break;
case Noob:
#endregion
result = WtfEnum .FileNotFound;
break;
}
return result;
}
#endregion
#region Public methods
private bool FoldingGoodButRegionsOpenToAbuseAndMistakes()
{
bool result = true;
#region Irrelevant logic
result = false;
#endregion
return result;
}
#endregion
I havenât noticed if itâs been said, but VS has plenty of automatic code folding features, WITHOUT using regions. Regions allow further, more programmer defined folds to be created.
VS even letâs you use code folding on other file types like HTML, XML, etc⌠(uh oh, here comes the XML debate again)
I use regions to prevent my boss from touching code that he doesnât understand. If he actually opens that code, then his head will explode, and, headless, he will start breaking the code in subtle ways that take days to unravel.
So my regions normally look like this:
â This region contains all the drawing code for this control.
â Do not edit this code unless you take the time to understand it.
â WARNING: This code is very complicated.
â Small changes may have effects that are not immediately visible.
#Region Drawing and GUI Code - Do Not Touch!
âŚ
#End Region
This usually keeps our code safe ⌠usually.
I also use regions to hide lists of private variables and public properties.