The Problem With Code Folding

The problem with Text Folding.

I hate chapter titles in books. When I open a book what do I see? The Table of Contents! Immediately I have a problem! I can’t see anything! Every time I open a book I have to manually turn past the damn Table of Contents. WTF? Each section of the book has a stupid Chapter Title. I want to see the damn text! If I want to know what the text is about I’ll read it! And some of these chapters are only one page long!!

I daresay being able to see the damn text is more important than having it meticulously segmented into pointless little named buckets, but apparently a lot of authors can’t get enough of stuffing their prose into pointless little named buckets. It’s as if they’ve forgotten what scanning – and an index – is for.

  1. Chapter titles are glorified comments.

  2. Chapter titles are used to sweep text under the rug. I once saw a book with only three chapters and it was 400 damn pages long!

  3. Chapter titles are used to mask excessive length. See #2.

  4. Chapter titles can hide deficiencies in your writing tools. Why does someone have to create these? They should be generated by the author’s word processor, or typewriter, or steno pad!! Aren’t all books the same? Protagonist, antagonist, love triangle, misunderstanding?

I urge authors to write stories that don’t need chapters to be readable, clear, and concise. I’m sure there are sane uses for chapter titles out there somewhere, but I rarely see them.

I think if codebases have to be really big, this is a good argument to use .NET partial classes. Separate the chunks of those big files into different files.

They may logically belong to the same class, but at least they are in different files.

And I don’t get what it is over users being afraid of having a lot of files. COBOL programming, anyone? Everything in there is just under ONE BIG FILE!

Folding functionality can be useful, to hide code that just isn’t important most of the time. Eclipse, for example, automatically folds all the import statements at the top of the file, since that kind of thing just isn’t relevant 99% of the time.

That said, this #region feature sounds like it’s being overused somewhat, as a workaround for having too-complicated code. Eclipse supports manually collapsing at the class and method level, but it’s not a feature I use very often - it’s almost always sufficient to use the outline view to get the high-level overview of the file, which can be set to filter out non-public methods, or private fields, etc…

Regions are like knives. Which can be used abusively, for poor reasons.

#region My Opinion

I use #region - so sue me! I think this is a non-issue, and your rant amounts to little more than whining.

That said, I completely respect your right to think differently. :stuck_out_tongue:

#endregion My Opinion

I have little problem with regions. They could be useful. I’ll tell you what I do have a problem with, and it is those F$#*@ tiny expand/collapse icons! They must have talked to Adobe cause those are other idiots who insist on having to click a 2x2 pixel area. Regions would be nice if there was some decent region management. I.e show/hide/collapse attributes,regions,intellisense and frankly I’d be a happy camper. And do away with those stupid rectangles around collapsed parts.

I was once going thru some 3rd party code where it actually made sense but it is either all or nothing here. You can expand everything easily enough but cannot collapse only certain parts.

Personally I don’t use regions, they piss me off because they’re completely unmanageable. When collapsed it is a gray frame bonanza and when expanded they create codefile garbage.

Regions aren’t evil in an of themselves. In fact, I’ve been longing for the idea to spread over into the T-SQL world.

The argument often used is that “if your code is long enough that you feel the need to clump together in a region, it probably needs to be ‘re-factored’”

This certainly doesn’t apply to SQL. If you break up a long SQL, for example, one with many nested queries, you could only do so by creating temp tables, which would result in introducing efficiencies.

Having regions in SQL would allow you to view the whole SQL on one screen (or whatever) and allow you to absorb the intent w/o seeing a list of 75 selected fields. I say, put them in a region and a comment with the options to see the details.

What Vis Studio needs is a way to custom-organize subs as the view, using a tree like interface and to save this view. The code itself would not be grouped in regions, the user would just be able to choose how he wanted to see the subs, much like looking at code in the class diagram-it’s just a view of the code.

#region opinion

This is a tool to be used at the discretion of the developer.
Your arguments are misplaced in my opinion and have more to do with coding practice than the usefulness of the tool itself.
It’s all a matter of organisation. Bad code is bad code hidden or otherwise. Now organisation is a useful thing in life and this is what I see the code folding tool as. I prefer to have them for hiding useless parts of code such as the platform invoke for instance, Or group several parts of code together with a semantic description of what’s in that region, say structs for example; but I use the tool sparingly I do think it’s bad practice when you start #region folding inside a class, but that depends on how big the class is and what you’re folding.
The tool is not to blame. It’s the bad carpenter that uses it.

#endregion opinion

Just to make a minor correction:

A host of IDE’s can use #region directives, and not just with C# and VB.NET. C and C++ IDEs are guilty of this crime also.


If you’re using #region you’re probably using visual studio and also more than likely coding classes, namespaces etc. which means you’re screwed before you’ve even started.

I agree about code folding anyway.

I see most of your points, but I still use them…

Mostly I use regions during construction. I work on my code in categorized pieces. If I am building a MembershipProvider I will code fold away the done pieces so I can focus on the not done pieces saving me scroll time and keeping my brain on task. When It’s done I remove them all and then I add regions to separate out the different types of code.

region Fields, region Properties, region Constructors, and region Methods. I always have mode code structured in that order, Fields at the top, then properties, then constructors, then methods. As such I like being able to collapse the fields and properties when I am adding constructors, or collapse the top 3 levels when I’m working on the methods.

For me it’s all about making it easier for me to focus what I am working on while scrolling as little as possible, and not having to search for anything at all. The less time I spend scrolling and using Ctrl:F the more productive I am.

I like other developers to follow my lead on my team, because if Bob adds a Field, I know exactly where that field should be, right above the closing #region tag for the Fields section, because they are in order of “Date Created”. Using this structure I can generally look at code someone else added on a later check in and I know what they added without having to look at the change log.

Nothing annoys me more than seeing a field declaration at the bottom of a class between a method and a property… It makes me cringe when all the fields aren’t together, and all the properties aren’t together, etc etc etc. The region pattern I use hints for people to put things in the write place in the code file. The right place being where everyone else on the team is putting things in the code file.

As such I find it greatly increases organization and team work on team based projects (multiple developers and source control.)

And VS 2013+ will expand code tags that contains the results of a search, and go to definition as well, both automatically unfold code.

Despite believing that regions … have a proper use, I have saw one year ago a super bad example for using regions that made me want to tear out my hair (but I have successfully hold myself back, because it is painful to do). It was refreshing to read this article, and I could agree with you. But because I believe that regions can be used in a proper way but never seen proper use before, I cannot really hate it as much as you do. (I’m sill looking for a good way to use it.)

I don’t quite remember what I have thought of it when I first saw regions (in the designer files), but probably believed that regions is strictly a Visual Studio feature for hiding generated code pieces so the (dumb) programmer don’t have to worry about, and the programmer should not use region by them self.

IMHO It is good to organize your code by whatever reasonable category you can find, but perhaps not with regions that are folded on the first time, yet they are foldable perhaps. Eclipse introduces configurable region like segments in Java code, that is either expanded, or collapsed when the file first opened if my memory serves right. I’m thinking of something like that.

1 Like

Ugh if #region was necessary for your code then something is wrong with your code or your project cleanup sort routine.

Can’t argue with what you said. Hopefully the team will be open to new ideas.

the best use of code folding is to use to collapse copyright comment at beginning of file, which developer is not interested to see in each file.

That is one of the few uses I can definitely support.

Code Folding is the best feature,

that is probably due to endless scrolling of Internet websites - which developers are about to get famous for saying coding in full sized code pages; which where made by apple phones for communicate the deed (in fashion);

and also because Visual Studio is horrible with no customization for the background color for the Collapsed #regions which had being programmed by Visual Studio perception on how to use the editor - that is auto formating by default with no white space free;

A precursor to my logic with this topic:

  1. I mainly work with Windows Forms applications
  2. I use modules to host commonly used methods throughout my application
  3. I always leave everything collapsed in every file and only expand what I’m working on or things I need to review

#2 Gives me a sort of MVVM style code pattern. I have a module called modHandling. This one module has 6,936 lines including white spaces. I used regions in this module to segregate certain methods by what part of the application they are for.

Between lines 2,098 and 6,936 I’ve used 11 regions. I didn’t always have regions here, but I’m so glad I added them, because now when I go to look for the method that creates columns for a certain gridview, I just scroll down the file until I see the region hosting it. Then I expand that region, and scroll down to the specific method for the particular GridView I’m working on, and then expand that.

Sure, I could CTRL+F and search “Sub CreatePRColumns” (because I remember the names to all these methods by heart), but that literally doesn’t feel right to me. From what I’ve discovered, there is no way you can get that same segregation with my particular situation without using regions and still make it easy to navigate visually.

All in all, programming ultimately comes down to two things: Skill and Efficiency. If regions make a programmer more efficient (such as myself), use them. If not, don’t. Easy as that.

1 Like

I’ll throw in one other helpful use case as well.
I have a Main View form in my application with 4 tabs, each having their own GridView.
[Picture 1 shows the form]

Each GridView has 3 main processes underlying it.

  1. GridView Events (such as visual formatting of items)
  2. Context Menu events for right click options
  3. Sub routines for general code blocks specific to working with that GridView

[Picture 2 shows the Regions used to segregate those 3 main components of each GridView]
Take a look at how I’ve used regions to organize those.

[Picture 3 shows how I’ve encapsulated specific methods to make it easier to navigate to when changes need made, and just how many methods there are in just one section.]
Now take a look at just how many methods are just for the Site Equipment GridView Events

Regions make it a whole lot easier for me to navigate to certain sections of this particular form and modify code as needed for whatever process I’m working with.

I hope this information sheds some light on how #Regions can be used effectively and efficiently.