Feature request: Allow the user to collapse marked regions of code

[samcan]

Justification
In large projects, the amount of code in each class can get unwieldy. For example, in one class I have a large number of defined properties which overwhelm the subs/functions in the class. Visual Studio/C# allows the user to mark certain areas of code as a named region which they can then collapse in the editor window to hide from view when working on other areas.

Right now I'm marking the areas using the following syntax:
'#Region Properties and '#EndRegion

But would love the ability to collapse these named regions.

Description
In the VBE, the user should be able to mark a certain region of code with '#Region <NAME> and '#EndRegion where <NAME> is the user's name for that particular region of code. This adds a collapse button next to that region of code which the user can then click to collapse it, showing only the region's name along with an expand button. The user can then click the expand button to show the region of code.

Additional context
Following is a screenshot showing collapsed regions in C#. This is a screenshot from the Visual Studio Marketplace.

I searched the issues database to see if anyone had already suggested this, but couldn't find anything. My apologies if this is a duplicate.

[Vogel612]

As it stands, we can't add collapsing to the VBE just yet, because we didn't find a reliable way to control the codepane of the VBE.
When we get to hijacking the editing process with our own avalon pane, scopes will become collapsible.

That being said, even if we have codepanes under our control, I personally very much dislike regions as a tool. As such I'd argue against implementing regions for Rubberduck, if only because I consider them an anti-pattern.

[retailcoder]

We'll get code folding for scopes, but something like #region simply isn't going to happen, sorry.

This post says everything that ever needs to be said about regions.

#EndRegion looks nice on a t-shirt though 😉

[mansellan]

So I'd like to make some counter-arguments here. First, some context. I used to use regions almost exactly as illustrated in @samcan 's post. Code felt cold and foreign without it. When I joined my current employer, I was challenged on it after my first commit, as no-one else did it, and they universally hated that I did it. It took a while, and some reading of posts like the one above, for me to let go of the habit, and to be honest, I haven't missed it one bit. Especially after I found Ctrl-M-O in Visual Studio,

That said, there are some legitimate use-cases:

• Grouping together large numbers of overloads of a method
• Allowing legacy code to be folded out of the way whilst it's being refactored
• Folding large chunks of data (e.g. base-64 strings) out of view

I agree that, in most cases, regions are a poor choice compared to refactoring. But given that, post-Avalon, this would be trivial to do, not adding it is a conscious choice. I just think it's a bit prescriptive to rule it out, even if it comes with a health warning!.

[bclothier]

Just to toss out a different take.... because we do want to encourage people to refactor their code rather than hiding the complexity, it might be more desirable to enable code folding over TODO markers (which implies creating a end marker for the same TODO). That would in turn encourage people to always label the section as something needing to do and hopefully encourage them to compose their code some more so that it's no longer necessary to fold code.

[retailcoder]

Let's keep the discussion going and ideas flowing, and defer implementation until we have a code pane to support code folding of any kind.

[samcan]

Hi,

I looked at the StackOverflow answer regarding regions, and while I get what it's trying to say about splitting a class into smaller classes as a class is doing too much, I don't feel like that's always applicable. In the project I'm working on right now, I've got about 15 properties for a class, which, because VBA has a very verbose implementation of properties, is overwhelming the number of subs/functions I have in my class, and the pieces are all directly related to the class they're a part of---I wouldn't just want to split the class into sub-classes for the sake of splitting them into sub-classes. I suppose I could create a separate data class that just has the properties and private variables from this class to help reduce its overall length, but supposedly that's another no-no (per https://refactoring.guru/smells/data-class).

I may have to take another look at the class and see if I can think of some other way to refactor it...

Thanks!

[retailcoder]

@samcan keep in mind that while the vast majority of the literature on OOP/SOLID is perfectly applicable to VBA, some of it remains impossible to do - e.g. in C# you could make a class partial and split it across different files; in many languages you can abuse inheritance and move members to a base class.
I'm not sure there are many downsides to moving a class' default interface properties into a tightly-coupled DTO (that DTO class could even be reused as a factory method parameter), effectively replacing all properties with a single, get-only property that yields the DTO. Seems a neat way to keep a default interface tidy.

Things get hairier when a class has its default interface and needs to implement one or more additional interfaces; the interface members must exist in that specific module for the code to even compile. If the interfaces aren't exactly ISP-compliant, that can make quite a lot of members to wade through.

[IvenBach]

past-Iven would have wanted regions. current-Iven, working mostly in VBA-Dev-Landia and after the SoftwareEngineering link above, feels like they would be abused more than they help.

I haven't missed it one bit. Especially after I found Ctrl-M-O in Visual Studio,

Having worked with small/simple code bases I feel lost/overwhelmed in any larger code base when seeing everything. Stepping up to the RD, which I still naively call a 'large' code base, was tough. I agree with @mansellan that 'Collapseto Definitions' makes it far easier to work. That alone made working on the RD code base less bewildering for me. Once that's available for VBA feels like that will make the difference for others too.