The Problem With Code Folding

I think I’m in agreement with Jeff, both about folding and about fitting in with your team. Unfortunately the team I joined likes code-folding.

I’m interested by the analogy with chapters in books. I guess all authors work differently, but I wonder if many start by writing out all their content in full and then deciding how to split it into separate chapters…? In my experience, that’s the approach people take to code-folding.

Like most things available to us, I guess the relative merit of #region depends on how sensibly it’s used.

For me, code-folding falls into the category of things developers do when they’re bored. Jeff - please write a post on things developers do when they’re bored :slight_smile:

You’re getting all foamy over nothing. I would put it the other way around. I’m sure there are some INsane uses of folding, but I find it extremely useful to get where I want to go in a large source file. If it were used to fold up entire groups of structures or functions, OK, that would be stupid. However, it’s much faster than scrolling through thousands of lines trying to visually scan for what I want, or hitting Ctrl-F and thinking up some phrase or variable that is in the approximate location of what I want.

I would think this would also help newcomers to a project (whom you just told to play nice! WTP!) get familiar with the overall structure of a source file.

Unfortunately for me (fortunate for you?) my work doesn’t take me into visual studio very often.

Agreed. When I first saw code folding and the #region directive, I thought it was the coolest thing. After using it for a while, I realized maintaining the #region’s costs time, and the increase in legibility is negligible. On top of that, visual studio by default does not search inside folded regions.

As an aside, XMLDoc’s verbosity is the one reason why I don’t use it. I prefer the JavaDoc syntax instead, which is a lot friendlier on human eyes. The slight loss of readability that comes with using JavaDoc is more than made up for by the very usable hyperlinked, cross-referenced HTML documentation I can generate from it.

I use regions. Tell me I can’t use regions and I’ll get upset. Seriously, regions are great. There are instances where regions are very effective at organizing certain code sections and I find in those instances they add to readability significantly. I definitely don’t use them where they are not needed. In fact, I don’t really use them that often, but when I do they become a valuable organizational tool.

Let’s please not do the it’s my way or it’s wrong kind of thing going. Since when was having options a bad thing. If you don’t like a feature, then don’t use it. If you don’t like the fact that you have to crawl through someone else’s code that uses regions, well, then that’s too bad, but I’m sure you’ll be able to cope. As you mention early in the post, you have to make some accommodations when you program as part of a team. Sure, the use of regions can be abused. Programmer’s can abuse lot’s of the tools available to them. Doesn’t mean they shouldn’t be allowed.

Come on, regions are not that big of a deal. Really.

@Jeff: The presence of so-called standard boilerplate regions like Public Constructors and Public Properties and Events is not a feature. It’s a bug.

Actually I’d go beyond that and say it is a failing of the language (at least in C#'s case).
To my mind a well-implemented class should be understandable purely from its public interface and associated comments. If you have to look inside a class to see what it does before you can use it then it is broken.

C# doesn’t use ‘header files’, or public/private blocks, so it lacks that tangible separation between the public and private methods. Using a #regions for ‘public methods’, ‘private methods’ etc just lets you (poorly) simulate that concept.

(Some folk are bound to say that the solution to this is to write an Interface for each class and then code to that - which is fine in theory and often useful to some degree, but it does get very wearing. Instead I tend to refer to the Object Browser to ensure my public interface makes sense.)

It all depends on how it is used. In the screenshot you used, the regions don’t clearly tell me what to expand if I’m looking for a particular method or property. Where I work, we use regions to group similar methods and properties together, naming them approprietly does help a lot when looking for something.

I’ve seen it used excessively and it does get annoying because it adds no value, but when used correctly, it’s a real benefit.

Gotta disagree.
I like a small number of regions to help organize the code. With a second window and with Resharper I can keep a File Structure window open to help me navigate within the file.
If I open a file that’s folded, a quick Ctl-M,Ctl-P opens it all up. No big.

You can do code folding in Emacs, either using outline mode, or one of folding modes (extensions). But it is done properly, which means using specially crafted comments, for example
/* {{{ Public Static Methods /

/
}}} */
where, of course, choice of comment markers depend on the programming language used. Using comments has the additional advantage of being useful even when all blocks are expanded. Also, it is not on by default.

As to navigating the code: incremental search and named or per file bookmarks are much better solution.

One obvious failing of the Visual Studio editor is that it doesn’t indicate which region(s) your cursor is currently in.

If it was displayed on the status bar then it might help prevent the situation where say, event handler methods get added outside the #region Event Handlers.

Even better would be if there were standard enforceable regions that could be checked by the compiler - so that if you use the standard #region Public Methods then it warns you if you add a public method outside that region.

Though ultimately, as Jeff says, the best solution would be that the editor just recognised such groups of methods and did the grouping for you without help.

Great post Jeff

I don’t mind the odd region here or there to logically group stuff together, but I really dislike the convention of putting things in regions according to accessibility. Here’s my own rant on this from a year ago…
http://mark-dot-net.blogspot.com/2007/06/visual-studio-regions.html

and thanks for the Ctrl-I incremental search tip. I didn’t even know that feature was in there

Some features are useful in the right hands, but frequently improperly used, or overused. Hungarian Notation would be a great example. You can use it to embed semantic information about otherwise-interchangeable C pointers, or you can use it to make your code pointlessly unreadable. Looks like we can add another feature to that category.

I’m not a big fan of #region. But I use them and find them more practical than extensive creation of partial files.

However, I agree with you that the editor should automatically offer to fold up common structural blocks for you. It should also collapse XMLDoc comments by default, maybe attributes too.

If you are using VS08 (and I believe it’s in VS05 too), you can force the IDE to open in expanded mode. Therefore you 'll get your unfolded appearance you are looking for.

Tools|Options then Text Editor, C#, Advanced and Outlining, Enter Outlining mode when files open.

I know, I know, it’s not perfect for you, but it does help you blend in with your team a bit more without the CTRL M + CTRL L

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?

Wow, 200 comments already, you seem to have touched a nerve…

I guess that my thought is that at least the developer is attempting to make the code easier to read… it’s hard enough getting developers to comment their code, let alone regions.

Definately a high class problem you have there.

Regions are great for organising my code sounds like a code smell to me. Your code ought to be organised already.

That said, C# and VB suffer (as do C++ and Java) from having all the code inline. Languages like Delphi, Modula2 etc that had separate sections to define the interface (in the sense of signature) of a class make code folding redundant.

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.

Dang Jeff you’ve gone crazy again :slight_smile: Regions are awesome for hiding dumb insignificant code while you concentrate on the crap code that has generated 37,000 different support calls. It certainly helps me concentrate. It’s really a question of if they’re being overused/abused in the codebase.

I’ll lend you a battlecruiser for your war, Jeff.

Regions are almost always a completely abused waste of time. Each person is inventing new uses for regions (almost always duplicating the basic functionality of the IDE. Regions for private / public / etc, are asinine and redundant, but worse still they encourage the developer to segregate these items even when the code would be clearer if they were all together).

I’m with you on regions, so often I’ve seen a region inside a class containing a nice chunk of related self-contained code that should really be an inner class. It’s a way for people to write procedural code inside a class. If you find yourself wanting to add a #region you should really look at your class and ask this question.

Do I have any functionality here that would be better split into an extra class?

I think most regions in code can be removed and replaced with better code structure

I’m guessing that Regions originally started as a way to hide all the auto-generated code from Winforms, since that’s where I first saw it. Then gradually the practice of using it to reduce a long classes into sections of methods, stubs, private data, etc, became popular from watching c# and vb demo videos and sample code. Still this type of sorting is a real need. Comments, annotations, and coding styles are all to help readability and with intent. I still think IDEs have a long way to go with helping programmers record intent and express conditions.