The Problem With Code Folding



I wholeheartedly disagree with you. Between this and your preference for …

 if (someString == )


 if (someString == string.Empty)

… I’m beginning to have my doubts on your content.


from Graham Stewart post
The worst thing that I saw in your post was cases. Using cases inside of classes can cause BIG problems in VB when integrating with certain visual objects. Honestly I have no idea if this is true in C# or not, being that My C experience is in C++.


Sorry Jeff, you are wrong on this one, but not for all the reasons above.

In my world, we receive massive XML (and custom) data files from other companies. We don’t dictate the format/schema, and only rarely can we convince them to change it from whatever absurd raw format they wanted to send us in the first place.

Imagine a health-care-related XML file with ~500 data elements logically grouped like this:

similar data to physician
similar data to physician

etc. These are manually loaded using C# because address1 can be blank for the physician but not the patient, whereas the zipext can be blank for anyone but the hospital. Also, each individual element has its own rules for different companies, different error messages that must be shown, and about 5 years worth of custom, client-specific enhancemen…err, hacks to get around random stuff they send to us.

With code folding, we can group hundreds of lines of code like this:

[-]#region physician
// CrazyClient42 can send us data without a physician lname tag
// CrazyClient18 can send us an empty or lname tag
xnTemp = IncomingXmlDocument.SelectSingleNode(//Root/physician/@lname);
if(xnTemp == null client != CrazyClient42)
throw new exception(Missing Physician Last Name);
if(string.IsNullOrEmpty(xnTemp.value) client != CrazyClient18)
throw new exception(Empty Physician Last Name);
PhysicianDataStructure.lname = xnTemp.value.trim();

… repeat for every data element in physician…

[+][#region hospital]

[+][#region patient]

If there is a problem with the XML file loading, we need to stop immediately and halt the process with the appropriate message. Using these regions has saved us countless minutes looking through hundreds of lines of similar-looking code.

Can you put these in their own functions instead of regions? I guess you could…you could even put them in their own files if you wanted to. You could put them in their own DLLs! But why? They really are all part of the same function: loading a given XML document, baby-sitting it every step of the way because you have to and storing the orderly data in a set of known programming structures.


I’ve always wished for a way, when browsing a class, to hide private methods/fields of that class. So I like #regions.

Ultimately though I’m in the format the crap out of it camp. We’ve been coding in plain text for too long. I want an IDE/language that treats code as a database, and lets me view functions, apply my own (not checked in!) tags, formatting, and organization. I want to be able to use rich formatting to, say, paste pictures in as comments. But most of all, I want to use the blink tag IN CODE. :slight_smile:


I think it’s useful to be able to organize code using regions. I want to hide stuff I’m not working with, scrolling up and down becomes tedious and icremental search does not work unless you want to keep remembering the name of every method, class etc.


Does anyone who dismisses regions as an excuse to hide crap code or avoid refactoring actually work in the real world? I’d love to spend time refactoring some of the poorly designed projects i’ve had to work on but I can’t because I have a steady stream of new jobs coming in which might actually help the company I work for turn over a profit. I can picture the conversation with my boss now.

Sorry boss, can I delay starting on project x for a couple of days, i’d like to do some work on project y

Why, whats wrong with it?

Well, nothing really, but the some of the classes could do with refactoring…

Anyone care to guess what the answer will be? I’m always re-assessing and where necessary trying to refactor my work but it’s something I have to fit into time between projects or in those rare instances where I find myself at a loose end.

There are a couple of people where I work who are the sort of people who get wound up about coding preferences and the like and blog about this sort of crap, who are coincidentally the least productive programmers we have.

In any case, joining a project and refusing to adopt any conventions that the other developer(s) may have taken time to use is plain arrogant. I hate hungarian notation, ‘m_’ variable prefixes etc but i’ll use them if it’s consistent with the project i’m working on. Likewise, I expect other developers to show my projects the same courtesy.


This is why I prefer editors like Vim (GVim for you Windows people).

I can control whether folds exists, how deep they go, where they start and stop and much more.


@Rick Scott: You could create some more elaborate way of doing things, like encapsulating search logic and exceptional situations, use object oriented programming and inheritance etc. That way there would be actual structures instead of hack regions.

When I design and program software, I can see all objects in my mind. So lets say I want to access the logic of CrazyCustomer33. I would know that it is in a subclass of parse logic eg. in ParseLogicCC33. So I just open that class instead of starting to search through hundreds or sometimes thousands of lines of code.


It seems the #region was your first wife that left you for you bset friend.
Couldn’t you find 50 more reasons why not to use #regions?

#regions is a great thing. Period.


folding is simply natural for c#. could not say that for c/c++ or f# or any other from top to bottom language.


God bless you, Jeff! Would that every programmer in the world would read your blog and put your words into practice!


i like code folding. when working with long code, it is very handy (to me, at least) to be able to just fold up the parts that i dont need to look at. Even when folded, search will still find stuff in folded code…

i’d much rather open a piece of source and see the fold comments denoting the different sections. This (in my opinion) is not only a form of documentation but also a high level organization tool. Even more so in team environments.

It sounds almost like the writer of this article is one of the ‘cowboy coders’ that they complain about at the top…

That’s just my 2 cents…


@I daresay being able to see the damn code is more important than having it meticulously segmented into six pointless little named buckets, but apparently a lot of programmers can’t get enough of stuffing their code into pointless little named buckets. It’s as if they’ve forgotten what the scroll bar – and incremental search – is for.

NO! Use #regions to aid model-driven software development, and use #regions to separate true concerns that can’t be identified by a tool, because you’ve yet to set-up an explicit open-closed interface.


Actually, Eclipse has this option also (fold methods and inner classes) without any #region thing, and I find it very useful when navigating the code base searching for bugs. It also helps me from getting my self into trouble. I mean it, if you’re doing some task and while rolling down the code you find some stupid comment, you laugh and break your concentration. Or even worse, you find stupid code and by the time you get to add your stuff, you’re actually thinking: Who made that crap? or Maybe I can apply some Spartan programming there and there goes your zone.
Good article thought, you’ve got to keep up with your opinions


I think #regions is a personal preference, some people like to see all the code they have, even though it’s 10,000 lines. Some people like to hide the contents of methods/functions they have written when they are done with it. I’m with the latter group.

When I’m done with a function, I hide the content of the function, leaving the function name and comment intact. The comment + function name should be enough to easily work out what the function does. If it’s not, you are a messy coder. There really shouldn’t be a need to see the content of a function when you are done with it. – how I usually do it


criminally overused in practice and heavily prone to abuse: Absolutely yes. 100%.

Show the meat. Hide the fluff if it really helps, but please don’t hide things to rote.

One-size-fits-all approaches always end up hiding what you really care about. And if your class is so big you need to organise it ‘like chapters in a book’ then for your own sake refactor it.

[Today’s smackdown seems to have struck a nerve, yes?]


I love regions. If I’m writing something long and winded, I can put pieces in separate regions and find them easier.

#region Structures
…put all my structures here
#endregion Structures

Let’s say I have a page of structures. I can fold this and I don’t have to look at them. When I look at my file, I see what I want to see. If I want it all, I do CTRL-L.

Just FYI.

I always name both sides of my region. Also, if you want to find the other end of a region, put the cursor on #region and hit CTRL-]. This works for squiggly-brackets too.

Visual Studio.


have to respectfully disagree.

#region puts good use of code grouping, where I put the methods in relative segments (like private and public attributes). This grouping also enables me to navigate to the method I’m interested in faster.

Althrough, it’s given that the regions need to be properly named in order for this to work.


To think the IDE should be responsible for grouping (with #region) Constants, Properties, Constructors, etc, together also assumes that all programmers organize their code in the same manner. I think people start forgetting that the way we use our IDE isn’t the same as the next guy.

Not everyone is going to organize their code in a way that can be predicted by the IDE. Regions seem to be a rational, flexible way to allow people to organize (or not) their code aside from the automatic folding already done.


Yea, I hate it too, nothing like coming up with another way to hide something that should not be hidden…