I’ll have to back up the VI (VIM) comment above. VI has great code folding. You can specify how it folds and tell it to remember your folds open/close when you come back to the file later (plus remember where your cursor should be).
Hard to be the efficiency of VIM if you know your language.
I like regions in the auto-generated code from some of the visual studio templates. Hiding all that crud is nice.
I’d never put them in my own code, and I remove them from it whenever I implement interface (it always sticks in a #Region - annoying).
#Regions don’t kill code, coders kill code (if they’ve got a #Region)
I also disagree. In team environments a consistent way of organising code makes things easier to navigate. It’s not always about finding something, I would argue that more of the time it’s about browsing through code that has been written by someone else - if you are familiar with the organisational structure of the code, its a great help.
Using regions is good practice.
Thumbs down
Just use that hot key you mentioned to expand them all and pretend they’re comments (they are comments!)
This is ridiculous. How could clearly defining the elements that make up a class be bad? If every class that is written had regions for:
Private Members [or Fields, or whatever]
Constructors
Properties
Public Events
Private Events [think WinForms]
Public Functions [or Methods]
Private Functions [or Methods]
… then it’s crystal clear where to find the code you are looking for. Someone reports a bug when they click Update in the customer screen of a web app or WinForm app? Well, go to the customer web page/form and look at the .Click event of the button in #region Private Events. There is a problem with saving the data of a customer to the database? Look for the .Save method in #region Public Functions. How could anyone not advocate a cleaner, logically laid-out code base, where ridiculous scrolling is not required?
We’ve gone down that route before, and it makes changes more difficult.
There’s nothing easier then simply putting the code exactly where everyone would look for it first.
We have pre-programmed regex searches that look by client name and those serve perfectly if we have to know if a particular client has a particular hack turned on at a moment’s notice (like on a conference call).
Complicating a long series of very simple lines of code is not an improvement.
If you’re constantly editing one small area of a giant file, why isn’t the part that changes frequently in a different file?
That’s stupid. Tha’d be like if you’re constantly retouching your car’s breaks, you should move the breaks to the back seat for easier access.
Regions are -like many tools- an excellent service the VS provides that could be overused, misused or well used.
Banning Regions just because you don’t know how to properly use them is foolish Jeff. You contradict yourself so many times… you don’t want visual bloat but you prefer to have a file opened in front of you with xxxxx lines of this is not the code you are looking for.
Grouping things in a reasonable way is because our brains do not have the power of the IDE to just jump back and forth of the code. Regions help us to hide things and group stuff.
I group all the Delegates/Events, Public properties, etc. Because I know when I open the file, what I’m looking for. I just expand the part I want to see. and search from there. Less scrolling.
Also VS2005 CRAWLS when the file is converted from 2003 and was a big form where there’s lots of Interface Designer code. So having Designer code collapsed really makes the file usable again.
I agree. In a team environment where you’re working on code not written by you, you’re usually more interested in how the code of the class interacts, not whether it’s a public instance method or a private static method.
An example as a maintainer: the first time I look at a class, I know I’m looking for something that sets Foo = Bar. I don’t know whether it’s a public instance method or not, this information is just noise. I’m interested in WHAT THE CLASS IS DOING, not whether the programmer chose to pass a ‘this’ pointer to a method or not.
#region folding hinders maintenance for people not familiar with the code.
One thing this post has surprised me with is how many people apparently seem to be using alternative editors (such as Vim or Emacs) to write C# code.
(Don’t want to start a One True Editor Holy War here - I’m just surprised that Unixy editors are so popular on an essentially Windowsy language)
I agree it’s a religious choice, but I do find some good uses for a #region (I’m still working on VS2005):
- In a WinForm, a #region is handy to collapse all the declaration of UserControls (as well as the InitializeComponents)
- Again, in WinForms, wrapping the Event Handlers in a #region is a good idea, since they never contain the real code for that Event, which is usually written in a separate method (to be used from different events, with different EventArgs)
I use #region a lot, it helps me organize the code overrides/implementations for the different base/interfaces of my classes.
But, to be honest, I’ve found a big negative point for #region: when many programmers write on the same classes, they do not share their mind patterns, and sometimes methods switch from a region to another with no apparent reason, new methods appear in a region they shouldn’t be in, etc.
My solution: I check all the code and decide where to place the regions, then I make sure I’m the last one to check-in all the files 
heh, once when I was contracting I saw the best ever use of regions.
A 10,000 line method, broken up by regions. 
My eyes still bleed to this day!
@Mark: from Graham Stewart post The worst thing that I saw in your post was cases…
Huh?? You might want to practise your code review skills!
There is a public method in the private methods region.
A private method in the public method region.
Folding the nasty region makes it look like Hackers get FileNotFound.
Folding the Irrelevant logic makes it look like result is true.
And I think I’ll carry on using switch/case statements in my code. 
I strongly disagree with Jeff: I find code folding very easy for the same reason why I don’t use a completely expanded tree inside the Explorer.
In my opinion Explorer sub-trees are collapsed to get a better overview and to find more easily the thing you’re looking for. That’s exactly why I use the #region directive.
Late to the party and didn’t read all the comments but still…
I don’t get all these negative comments. Especially those that say other IDE’s (eclipse?) do it automatically. That means you are using the tool wrong.
tasks for your IDE (in some tree for example or whatever):
- Group members by public/private
- ordering members on name
- mark your constructors
- fold each function separately (if you really want to do that)
- separate list of properties and functions
- …
that is all technical.
But good luck letting your IDE group functions based on businness logic. It just can’t.
Regions also will not make those decisions for you. So the hard work is still yours (yes it can get complicated it larger projects). But at least now you have something to work with.
I agree. Its not nice to have a method folding ability when it folds the method and comments separately leaving you 2 folded things instead of 1 (the method with comments). I bet Visual Studio makers did method folding the easy way and didn’t allow wiser folding, because wiser folding would have been so much harder to be implemented.
icremental search does not work unless you want to keep remembering the name of every method, class etc.
Yes, god forbid we actually remember the names of the routines and variables we use…
@wenke this is awesome!
http://img184.imageshack.us/img184/8929/72ve0ptu4iry6.jpg
Some final points as the discussion winds down:
-
I personally find the way Visual Studio handles default folding to be completely unsatisfactory bordering on useless. It is entirely possible other editors (Vim, Emacs, Eclipse) handle this in a more rational way. I agree that lots of optional folding can and should be done exclusively by the editor.
-
Folding doesn’t kill code, Programmers kill code. Yes, it is possible to use folding in a rational, sensible, restrained way. It is a pity that I almost never see it used that way in the Visual Studio ecosystem, though. It’s typically what you see pictured in the blog post.
Heh, I think I’m beginning to get the smackdown model, some interesting comments have emerged here.
I’ve used regions in moderation in the past with some success, though I could take or leave it. As usual though, my opinions suffer from never having to have maintained a large project.
One place I used to use regions all the time was for properties, to wrap up the boilerplate getter and setter code. Fortunately that problem has largely been solved with automatic properties (and hopefully we’ll see automatic backing variables in the next version of C#).
Several people have expressed a disbelief that you need to manually specify regions for code folding. The truth of the matter is that VS does quite a bit of automatic folding, though not to the granularity of most other editors. You can fold using directives, namespaces, comments (including XML comments), classes and methods (I might have missed some) but not things like conditionals and loops. Personally I’ve never had a need to fold at the level of individual conditionals and loops (if you do, it probably needs to be refactored) but I can’t see it would be something terrible difficult to add to the IDE and it most likely has already been considered, so I wonder why it hasn’t.
I hate it when you implement the interface in Visual studio and it auto-adds regions around the generated code. And when you add the interface and click it again, you get yet another region. Bad.
You can turn that off in Options-Text Editor-[Language]-Advanced-Advanced. I do think it’s the wrong default though.
Errr… I use regions in the VB.NET Express IDE and it does NOT automatically fold them closed every time I open up a file.
I think it may remember them in the user options file of the project, which tends not to be distributed or source controlled.
So Jeff, do you use XMLDoc comments? I’ve used them for a library I wrote that I thought might end up being public and I hate them. They clutter up the code so much. Do you think it’s bad form to stick with standard comments for internal projects where you don’t really need a help document?
I find XMLDoc comments incredibly useful, even for internal/personal projects. Remember if your using Intellisense the XMLDoc comments come up in the tooltips which, if you’ve not touched the project in a while can be extremely useful in remembering what a particular method does or one of it’s bizarre edge cases. You can collapse up XMLDoc comments, though annoyingly there isn’t an option to collapse them all at once.
If the code would fold with one click to give you a nice clean definition, that would perhaps make it worthwhile. But it doesn’t. Particularly if you have regions within your class.
Forgive me if I misunderstood but you can collapse to definitions (Context Menu-Outlining-Collapse to Definitions). It doesn’t show just the public interface (Object Browser is good for that) but it makes it easier to see. Of course it doesn’t play well with regions, as someone else pointed out.
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.
Of course, Jeff has stated that he hates trees too 
Wow, loads of comments.
I had to admit to being old school and not being a big fan of code folding. If you’re working through somebody else’s code then it breaks the flow of the code. I know it’s hidden in plain sight but that’s how it works for me.
To be honest a lot of the more complex code I’ve seen which is packed regions and comments and everything else could have been done with a lot simipler code.
The presence of massive XMLDoc comments bothers me as well. It’s necessary, but it gets in the way so often.
Not really, you can put XML docs in a separate file and include them. Here’s an example: http://www.codeplex.com/thehelpertrinity/SourceControl/FileView.aspx?itemId=2259changeSetId=7821 (scroll down to the members).
What’s necessary is a tool that manages all this for us, built right into VS. It’s something I’ve wanted to write for a long time, but just never got around to it.
Got a bunch of boring boilerplate code that makes your eyes water? A slew of ugly, gnarly code that nobody in their right mind wants to look at? Long, horrible spaghetti code blocks?
Perhaps you’re doing the dirty job of maintaining someone’s legacy code which looks like the afore-mentioned. In that case, it might be useful to close the code into regions that you can get out of your sight once you checked and double-checked them: Here’s that ugly hack from 20 years ago, I just made sure it has no side-effects on what I’m doing, so let’s get those 500 lines out of the way so I don’t have to scroll all the time.
Sure beats rowing the mouse wheel. Or imagine control-effing in vi!