Using @Folder Annotations
The Code Explorer, and eventually other Rubberduck features too, has the ability to organize modules into folders, using annotations.
By default, Rubberduck puts all new modules under a folder named after the VBProject:
'@Folder("ProjectName")
Option Explicit
Simply use the same annotation in all modules that need to be in the same folder.
To create subfolders, use the . dot to separate parent and child folders:
'@Folder("Parent.Child.SubChild")
Option Explicit
Folder names should be legal Windows file folder names (there are plans to eventually honor the folder structure when exporting/importing modules), but the recommendation is to use dot-separated PascalCase legal VBA identifiers - the idea stemming from .NET namespaces.
When a folder node is selected in the Code Explorer, the bottom panel displays the corresponding annotation for it:
No. VBA doesn't support namespaces, therefore each module under a given project must still have a unique name.
No. Folders don't really exist: they are merely a UI rendering of annotation comments in existing modules - it's smokes & mirrors: modules determine what folders exist. Without a module annotation that brings it into existence, a folder can't be created.
We do have plans to eventually build tooling to help maintain @Folder annotations though, and make it easier to move modules from one folder to another.
How you organize your code is entirely up to you. However we strongly encourage you to regroup modules by functionality rather than by module type. A @Folder("Class Modules") folder would be emulating the VBE's vanilla behavior, which is rather sad and doesn't really help organizing anything. Grouping by functionality however, enables having a feature's entry point macro, its UserForm UI, and all the specific classes it needs, under the same folder. The Battleship project makes a great example of how an object-oriented VBA project might be organized:
rubberduckvba.com
© 2014-2021 Rubberduck project contributors