Annotation and setting for hidden project/folder/component/members in Code Explorer

[ThunderFrame]

COM has hidden members, but VBA never did (with the exception of some very special cases).

It might be useful to sometimes have members be hidden in Code Explorer, but have the visibility configurable in the Rubberduck settings.

Maybe annotations like:

'Anywhere in a Project
@HiddenProject

'Leading underscores for hidden Folders
@Folder _MyHiddenModules

'Inside a member
Sub Foo()
    '@HiddenMember
End Sub

[retailcoder]

What's a compelling reason to use navigation features to make something less navigatable?

[ThunderFrame]

Sometimes less is more

If you have 100 members in a module, but most of them are behind the scenes or deprecated members, you might not want them visible when you're trying to navigate the important members.

Getting the crud out of the way makes seeing the important members easier

For the same reasons that COM uses hidden members:

• Deprecated members
• Undocumented features
• members intended for advanced users
• administrative functions

[Hosch250]

Delete deprecated members, don't use undocumented features (AKA bugs).

[retailcoder]

Actually an @Obsolete annotation would be nice. We're a refactoring tool after all, facilitating incremental non-breaking changes; marking members as obsolete is useful for the transition, it could cause its references to trigger an ObsoleteMemberCallInspectionResult, which makes it pretty easy to see what's left to tweak.

And the Code Explorer could show obsolete members greyed-out & strikethrough. I can see a toggle button (like the show/hide signatures toggle) to show/hide them. But then, just plain @Hidden seems wrong. I'd think of it more like some @Category parameterized annotation:

'@Category("Handlers")
Private Sub UserForm_Load()
End Sub

And then we could replace the togglebuttons by a drop-down menu with as many items as the user categories are available (hmm..), including one to rule them all (e.g. "select all/none")... or perhaps they could even be regrouped into sub-folders under module nodes...

[daFreeMan]

I think, @retailcoder, that your method gives me the option to use '@Category("Deprecated"), correct?

This way, I can rewrite a process with the intention of changing all the call sites, but allowing the old ones to still function on the old method until I get this fire put out and have time to change all the call sites.

[retailcoder]

@daFreeMan correct... although I'd probably make an inspection to suggest using @Obsolete instead, so that RD can understand these members as such (and display/toggle them accordingly in the Code Explorer).

[Vogel612]

I like the idea of an '@Obsolete, but the categorization is something that hints at an underlying design issue in the code. If you can reasonably categorize members in the Code Explorer, your Module is most probably doing too much.

Instead of fixing the symptom, Rubberduck should point to the root cause. What I'm trying to get at here is a Hint or Warning Inspection that flags modules with high LCOM values. Those are exactly the modules that would "benefit" from a '@Category("something")

note: LCOM refers to "Lack of Cohesion in Methods". Semantically related methods should theoretically access the same fields (in a class) or module-members. Accordingly we can attempt to measure how well-scoped a module is by calculating the LCOM value of said module. Unfortunately there's quite some ways to do that ☹️

[retailcoder]

@Vogel612 interesting... I was seeing it more as a "temporary" tool to, say, help tame a monstrous inherited code base you're trying to refactor bit by bit.

[PeterMTaylor]

So theoretically speaking, our measure as in metrics of LCOM here may supports our forward thinking for code path analysis

[rubberduck203]

So, I can see both arguments there. I think Vogel's right, I wouldn't want to do something that supports bad habits, but on the flip side, having a tool to help categorize methods temporarily in preparation for an extract class refactoring could be useful. Question is, is it useful enough to warrant implementing?

[rubberduck203]

To clarify, I'm speaking of the @Category thing, not the original request. Seems we got a bit off track from the original issue.