Jeff,
if code is not readable, or if it is readable only if folded, it is very likely that it is not the best cut of code.
Folding is for laundry. Optimization/Refactoring is for code.
I call it cheating.
I agree with Jeff enitrely about this, though I am not neccessarily qualified to comment.
Iām a PHP5 developer and I use EditPlus as my editor. It has a kind of āhacked inā code folding which turns out to be exactly what I want - it gives you the little expand/collapse button for any section of code that is at the same level of indentation. Its not very elegant but it has a suprisingly high percentage of the value of real code folding without any of the effort. (Your code is all properly indented, right?)
I donāt need to hide away class attributes, getters and setters and such because PHP doesnāt have any of that crap unless you want it - and then you want to see it. What I do sometimes want to do is things like collapse the ātrueā section of a large
if( ā¦ )
{
ā¦
}
else
{
ā¦
}
block so I can see the condition right next to what happens if it is false. Or hiding away divs in a HTML/template file so that I can see the surrounding structure (hunting for that unclosed tag!).
It is zero effort on my part and is there for the very rare occassions that I want to use it. If you want to give your region a description, just use a comment 
I prefer KDevelop/Kateās way of handling it: Every block-level statement (ie, anything within braces) is collapsible. So are similar block-level statements in languages like Python, which donāt use curly braces.
In KDE4, Kate is also capable of highlighting a block if you mouse-over its collapserā¦
And yes, it can handle #regions inside C# code too! I just tried.
clearly, all those years of web developing have saved you from seeing any problems, which actually do require a huge ugly block of code to solveā¦ #region is handy if you have such a block of code, and with MSVS its neatly wrapped into the ide so you just select the area and choose to outline it.
generally i am in favour of splitting things out into seperate files, however once it gets down to the one method level, i think its pretty silly to split it into more procedures/functions just for the sake of keeping it in smaller chunks. sure you /can/ wrap it into lots of little procedures, but iām not a fan, as it breaks the ability to read the whole code in sequence without swapping files, or moving around in a large file.
at the end of the day if you want to see what is in the region, you expand itā¦ i really fail to see the big deal there as encapsulating things in procedures has precisely the same problems in terms of maintainability and readability which have been described in the article for regions, except for that nebulous point about it being like a glorified commentā¦ if anything its slightly worse because you canāt expand the procedure in place to see its precise effect, but need to use some (implicitly error prone) thinking to substitute variables and remember things between two different files etcā¦
can anyone remember the early visual basics btw? they had this awesome feature where by you looked at one procedure at a time in the editor, even though they all came from the same file. its a shame they dropped it in vb 5 or 6 (canāt remember which). i think that old feature is a much, MUCH, better solution than what we currently have in the more recent visual studio products.
Jeff, Jeff, Jeffā¦
Have you truly LOST it and gone all religious on us? Itās a formatting technique, my friend. Properly used, folding regions allow us to reduce the problem set by managing the complexity of a code file. That IS what our friend Steve McConnel preaches, isnāt it? That our goal is to manage complexity?
With strategic use of folding regions, we can keep the screen clear of code irrelevant to our immediate purpose. Your argument that irrelevant code belongs in a different file depends entirely on context: the small part of the code I am working on may very much belong in the file, but I donāt want my eyes continually distracted by code for methods and such that have nothing to do with the particular problem Iām working.
How do YOU know what I want to focus on? What SPECIFIC thing Iām trying to understand or debug? How do YOU know that the best way to organize my code for focusing on one problem may be completely counterintuitive to the solving of a different one? Being able to collectively collapse/expand regions of the code AS NEEDED is a great way to keep your mental focus flexible.
Iām a fan of yours, and I mostly agree with your musings/insights, etc., but Iām afraid if we were on the same programming team, Iād be standing my ground on this one.
shash: visual studio provides the same functionality out of the box, minus the selection thing you mentioned, which does sound useful. 
I think Regions were introduced to .NET because the Microsoft programmers had the problem of autogenerated code. They needed a way to tell us hands off to the Web Form Designer Generated Code section. In 2005 and beyond, they simply introduced another feature, Partial Classes, that got rid of the the horrible hand off region section. Now, the MS developers can put all of their code in one file, and leave a clean file for us to work in.
I will second the comment that someone above made about VB6. There was a button in VB6 that you could press to view only the currently selected function. I used this all the time in order to make my scroll bar increase from hairline size to something I could actually click on.
In my opinion, regions and collapsible code have the same function in that they allow you to shrink the size of your scrollbar at will.
Generally, I think #regions are helpful, when used in moderation. I like each of my files structured similarly (declarations first, properties second, events third, and public/private methods last). Because of this, I usually wrap the declarations, properties, or both into #regions so that when I open a file, I donāt see a bunch of rarely touched code. When you say that everyone should be able to see all the (crappy) code, I agree; however, I donāt think we should have to look at a few pages of declarations/properties that are probably fine. If I know there is a bug on Page_Load, I donāt want to have to scroll down a ways to see the beginning of it. Also, this doesnāt take much time to type. When I create a new file, I easily the #regions using a code snippet on my machine. You said that the editor should automatically offer to fold up these common structural blocks for you! Unfortunately, this doesnāt happen now, so I will have to do it in the meantime. If the next version of Visual Studio starts to do this, then maybe I will drop #regions altogether.
Why, exactly, are we writing code to accommodate the editor? It boggles my mind that weād add significant lines of code to our project that do nothing but offer organizational hints to the editor.
Did you actually say that?
I hope you are not wasting your time filing your documents in relevant folders, only to have the cabinet look organized. Geezā¦ the health insurance cover isnāt going to increase just coz you filed it! And also you should spread them all out on your floor, so that you can see ALL of them ALL the time.
Reducing visual noise is a wonderful thing. If I donāt currently need it, I donāt want to see it. Within code files, MS chooses the plus/minus expand/collapse approach as a big stick to get this accomplished. Regions allow us to introduce collapsibility into our code that isnāt provided out-of-the-box.
This is analogous to menus, treeviews, toolbars, etc in UI design. You can use these organizational tools to make things easier to use and find, or you can create a mess.
Whether you implement regions in a useful way is up to you.
Youāre not just advocating abandoning #region you got it in for comments to!? You gone CRAZY man!
Ditching regions and just having the option to have it open folded down to signatures would work for me, but that said Iād also like some options to allow me to sort methods (in a similar way to the current sort usings). I think that maybe because I also like to use class and method selector drop downs, as well as right click - go to definition, so alphabetical works for me.
As for comments I think Iād like to see the class and method comments moved to a seperate file as theyāve rarely been useful on code Iām working on. Iāve only really found them useful when you got the dll for some third party library and no source to reference, even then Iāve often had to resort to reflector to find out whatās going on as theyāre often written by people who know how the library works without enough consideration for those who donāt.
Like most things, I have no problem with regions when used in moderation. For example, in my current environment, we have classes that have a lot of constants (sometimes as many as 100) inside of a single class. Itās nice to wrap these up in a region, as well as other code thatās important for the process to function but not important to look at.
Test fixtures are another place that I occasionally use regions. There may be a few hundred lines of SetUp and TearDown, which arenāt interesting once itās completed.
But I do agree that regions just for the sake of having them is usually unnecessary. I definitely donāt like the regions used in the sample in this article - if youāre going to use them over an entire codefile, Iād rather see them as logical groupings instead of just by the type of members.
Those who point out auto region expanding miss the core problem with regions ā if your coworkers are praying at the idol called regions, that externality infects the codebase. It strongly motivates how the code is structured, conforming with a generally poorly thought out use for regions.
Seriously, when people talk about accessibility or finding methods / properties / fields, and how regions help the same, it screams from the mountaintop that they are woefully unaware of the rudimentary features of the IDE (guess what ā it already tracks all of these, each navigable in the desired manner when the need arises).
Jeff, I think you take this a bit too far. Firstly, you get a little sloppy with your argument:
The editor should automatically offer to fold up these common structural blocks for you!
This came right after all the argumentation that folding is so bad because it hides code that shouldnāt be hidden (which I happen to think was good argumentation).
One other thing - folding can be useful without all the problems you have with it. Take Emacs folding for example - if you need to refactor a function, but donāt know all the commands or keyboard combos that have regional effect instead of buffer effect, you can use folding to put a region into a buffer of itās own, and then use buffer-wide commands there, and then jump back into the original buffer with the edits you made intact. Folding can be useful for things other than just hiding code.
Just a quick comment to say Thank You, Jeff.
I just had a bad, bad, bad moment last week when I opened the Nth file that was all #region-ed. My scream of āAAARGH !ā was greeted by blank stares (and a few bad looks) in the room. sigh
I use āviā folding with āset foldmethod=markerā all the time.
I only fold up functions, however, and my 1st line of the fold has enough info to infer what the function does.
This allows me to see what functions are available at a glance,
while working on the main body of the code (or while looking at a new function in progress).
vi (actually vim) will drop me back off where I was upon opening the file, so if Iām already in a fold, itās open when I start.
When working with fairly standalone application and a small developer base, the codebase resides nicely in a single file. This helps hide any deficiencies in the infrastructure, such as poor installation/distribution support and versioning
So I find the ability to fold code (and textfiles of notes) very valuableā¦ but with any āfeatureā of the editor, it can be abused.
Jeff,
Not being very constructive now, are we? Sure regions can be bad when used in the wrong way, as stated in many of comments. I can feel your pain since the code Iām working with atm is full of all the wrong kind of regions. But that is no reason to outright outlaw the usage of regions. Used in the right way they can be quite a help.
Better to educate the community of when and how to use regions and in the end we will all be better off.
It isnāt hard to toggle outlining, are we really getting to the point where weāre complaining about the effort involved in hitting a shortcut key?
I use regions quite often, but I also treat them a little differently. I keep them all expanded, but I color the directives a bright pink so they stand out. I use these bright pink directives to group static members from instance members, properties from methods from events, etc. I can quickly see them as I scroll through the file. You can also quickly jump to regions if youāre consistent in your naming.
I have been usisng a folding editor for 10 years or more. yes it can hide lots of bad code, but conversly, when I open a file I can see instantly in front of me the structure of the module. Without folding I temd to see half a page of includes, and quite often some helper functions - this does nothing for me.
Our deperatment is fairly 50/50 split on folding, but we all get along!