Roadmap
We try hard to keep our issues list nicely organized, since we use it not only to document bugs, but also to document our roadmap and feature requests. Some features are nice to have, but we're a small team and there's a lot of work on the core features alone - any open issue that involves coding against the core API (without modifying the API) are up-for-grabs, even if there's no green label to say so; more involved features might require varying degrees of modifications to that core API: they're up-for-grabs as well, but we tend to rate them with a higher "difficulty level", depending on how deep the rabbit hole goes.
Issues labelled "bug" are also up-for-grabs, although there are easier ways to contribute to the project!
Rubberduck has been around for a few years already, and we still have a gazillion ideas to enhance every single one of its major features.
Traversing a tree structure representing the user's VBA code, Rubberduck is able to make suggestions on naming and code constructs being used, recommend refactorings and point out issues such as dead code, unused variables and members, etc. Each inspection/quick-fix is a mini-feature in itself; some are very simple, some are very complex - and all are fun and rewarding to implement.
To implement a new inspection, we add a new class that we derive from the InspectionBase or ParseTreeInspectionBase class. The base class provides access to the user's code, and requires you to override a method that returns an IEnumerable<IInspectionResult>. There are two types of results: those that target a Declaration, and those that target an IdentifierReference - both encapsulate information about how to navigate to [where we expect] that result [to be].
Quickfixes inherit the QuickFixBase class, which provides the boilerplate implementation for the IQuickFix interface. The Fix method is abstract, and receives the IInspectionResult with an IRewriteSession for its parameters: that's the method you override to assess the inspection result and its target, and use the rewriter API to work not with strings in the code pane, but with tokens in a token stream. This stream is the tokenized input code - the VBA code, processed through our VBA lexer (a grammar that defines the language's tokens, ideally as per spec). During normal parsing operations, the stream is fed into the parser, which produces a parse tree, which we can traverse and do all kinds of fun stuff with! During a rewrite session, a quickfix gets a rather surgical access to the user code - we can just go and replace any token with any string, and we don't have to worry about all the pitfalls of dealing with a VBA code pane, since the rewrite session collects a series of operations that are all carried in sequence to result with the new content: and since the token stream contains the entire code for the entire module, Rubberduck rewrites every modules entirely, exactly once, for every module it modifies.
The fact that this means a project with many small, specialized classes implementing small, specialized interfaces, will probably perform better than an equivalent project with much fewer but much larger modules with many more responsibilities and library dependencies, is therefore a completely fortuitous side-effect.
There are well over 250 open issues and as many awesome ideas to turn into awesome tools for the VBA community!
The roadmap, as far as inspections are concerned, is to do whatever it takes to implement as many inspections as we can; inspections with a Performance inspection type, others with a ObjectModelOpportunities inspection type that hint at better uses of e.g. the Excel Range API; the ability to essentially evaluate VBA expressions and warn about heuristically unreachable code, recursive calls, infinite loops, etc. Anything we can think of, really.
There's a rather complete catalog of refactorings at refactoring.com. Not all are relevant or even possible to implement in VBA or VB6 (e.g. "extract superclass"), but that would give a good idea for what would be in scope for this feature.
Refactorings use the same rewriter API as inspection quickfixes, but they can often be much more complex and require user input. The roadmap includes implementing a "preview" dialog for every single one of them, where the user can review (and navigate to) the impacted code, perhaps exclude a subset of the changes, and validate or cancel the operation.
One special refactoring, is Extract Method. That one is extremely complex, and very important to get right. Most other refactorings are much simpler to implement, and pull requests are more than welcome!
The Rubberduck project was kindly offered the original VB6 source code of the Smart Indenter add-in. Since we cannot compile VB6 code in a .NET project, we ported it to C#, refactored it, tested it to death, fixed a number of bugs and edge cases, enhanced it with a number of new features.
Adding new indenter features isn't something we're prioritizing at the moment: the next step with this feature is to make it work off parse trees, which will greatly help fixing the few remaining edge cases... and further enhancing it.
The feature that started it all. Unit testing has seen massive improvements over the years, and is ripe for the next level. Will you be the one to add support for data-driven tests?
The Rubberduck.Fakes COM API can always be enhanced with new VBA runtime hooks, and we have a vision of an actual mocking framework too - one that could mock any COM interface, be it a class defined in any referenced COM type library or, if we're lucky, a VBA user class. That's right: the proverbial Holy Grail is almost in sight. If/when Rubberduck can instantiate a VBA class, we will unlock the ability to expose a Rubberduck.IoC COM API for inversion of control and automatic dependency injection. Yes, we're that crazy.
Rubberduck's scope is very, very large. We want to enhance the VBIDE in every way we can. Like, replacing the VBE's code panes with our own. Then we could support theming, custom syntax highlighting, replace the MDI client with a more modern tear-tabs SDI UI, code block folding, implement our custom enhanced IntelliSense, render inspection results as actionable squiggly underlines, ...anything we can think of. The biggest challenge lies in keeping all that awesomeness enabled in break mode, i.e. finding a way to hook into the debugger, and accessing breakpoints. But that's all just dreams right now.
rubberduckvba.com
© 2014-2021 Rubberduck project contributors