Features

More than just comments, annotations provide Rubberduck with actionable metadata that is used to support Rubberduck-specific features, such as unit testing, or custom folers in the Code Explorer toolwindow

A specific subset of annotations work in conjunction with inspections and quick-fixes, to surface hidden module and member attributes that are otherwise only editable by exporting the module and editing in a text editor, then re-importing the modified module into the project: Rubberduck automates this, and that gives you full control over how your class modules behave.

As the only features that directly interferes with typing code in the editor, auto-completion features can be disabled with a single setting.

Future plans include block completion (with auto-indent) and some form of auto-correct, for example to turn ? into Debug.Print as you type it.

Once Rubberduck built its internal representation of your project, it gives it back to you in a tree view that you get to organize into a custom folder hierarchy. This toolwindow intends to replace the VBE’s Project Explorer with a searcheable bird’s eye overview of your project that can be drilled down to member level, optionally showing member signatures; its rich features make it an irreplaceable companion.

Rubberduck computes a number of interesting metrics that can be reviewed with this tool to identify potentially problematic areas of a project.

Metrics include line count, nesting levels, and cyclomatic complexity... currently delivered in a rather underwhelming user interface - this feature has great potential, are you the contributor it’s waiting for?

The VBE does not have a status bar, so we improvised one with a label control. Rubberduck uses its command/status bar to show parser state and selection-sensitive information.

Rubberduck builds its own internal representation of the code, and then proceeds to analyze it. Each individual inspection can easily be disabled, or configured to issue inspection results at different severity levels ranging from Hint to Error.

Use the Inspection Results toolwindow to review Rubberduck’s findings, search, filter, regroup results by inspection, location, type, or severity. Each inspection result comes with a detailed description of what’s being flagged and why, so you can make an enlightened decision.

Being able to quickly find what you’re looking for is essential. Rubberduck supercharges the VBE’s navigation capabilities and makes it easy to quickly locate and jump to all references to a given member (without losing it in a sea of irrelevant same-name identifiers).

Decoupled, object-oriented code particularly benefits from the addition of interface-related navigation tooling, as well.

From the Inspection Results toolwindow, select an inspection result; the Fix dropdown menu lists all available quick-fixes for the selected result. Alternatively, simply right-click the result you want to apply a quick-fix to, and select the appropriate fix from the context menu.

Keep in mind that while static code analysis can easily and reliably spot syntactical elements (e.g. access modifiers, implicit keywords, etc.), analysis of code semantics is only as accurate as the internal representation of the code, and while 100% accuracy is the goal, in many cases it’s simply impossible: late-bound member calls (implicit or not) cannot be resolved, for example procedures invoked outside the VBA project (e.g. Excel user-defined functions, macros invoked by Access reports, etc.) are going to be reported as not used. Never blindly apply a quick-fix across an entire scope, module, or project, without first reviewing every individual result for a given inspection.

Before Rubberduck, the only refactoring-like tool in the VBE was... Find/Replace (Ctrl+H), which treats the code as, essentially, plain text: it does not differenciate two local variables named foo in two different scopes, and unless you search for whole words only then it will also find parts of identifier names that match, and it will not be able to tell an actual identifier from a string literal.

Rubberduck changes that: when you refactor/rename a variable, only that variable gets renamed, and all its (early-bound) usages get updated. Rubberduck has several refactorings to offer - not just rename, each designed for specific operations that would otherwise be tedious or bug-prone.

Perhaps one of the most painful features of the VBE, is its references dialog. Rubberduck reinvents this wheel and gives you a search box to easily locate the library you’re looking for.

A tool that can tear apart any VBScript-flavor RegEx pattern, and explain what every part of it does.

Future versions could enhance this feature with an expression builder and evaluator, and facilitate building regular expressions without leaving the VBE.

Rubberduck saves its configuration into a xml document. If no configuration file is present at startup, Rubberduck uses preconfigured defaults.

Quickly apply consistent and completely configurable indentation across an entire procedure, module, or project, with just a few clicks - or a hotkey. The VB6 source code of the original 32-bit Smart Indenter add-in was graciously offered to the Rubberduck project by its owners, licensed under GPLv3. Try it here!

If you have Smart Indenter installed when Rubberduck first launches, you will be prompted to import your Smart Indenter settings into Rubberduck.

Not all code is testable. Code with side-effects on global state cannot be tested; code that accesses a file system, a network, or that needs a database connection, cannot be tested. However, techniques such as stubbing and mocking exist to make unit testing possible for code that is written against abstractions - in object-oriented programming (OOP), code that adheres to the S.O.L.I.D. principles is testable code. VBA procedures that manipulate worksheets? Not so much... for now anyway.

Excel user-defined functions (UDF) that take in all their inputs as parameters are pure functions, and pure functions can (and arguably should!) be unit-tested. VBA and VB6 applications that use class modules and adhere to the language-agnostic principles that guide OOP design, can use Rubberduck to write a well-organised, boilerplate-free test suite.

If you are just starting to learn VBA, unit testing may be too advanced for now, but know that everything you learn while learning unit testing in VBA will be applicable all along your journey into programming, and that can only be a very good thing.

While Rubberduck was first developed for VBA, a lot of effort was put into getting it to also work in the stand-alone, classic VB6 IDE. Go on now, refactor that legacy code and get it unit-tested!