Code Explorer – does it replace the VBE’s Project Explorer?

Version 1.21 will feature a Code Explorer getting closer to where we envision it:

Just like the Project Explorer we can now toggle folders on and off, and components are sorted alphabetically. We can add standard and class modules, even test modules, open the designer when a form is selected – we can even run all tests from there if we want.

The Code Explorer is a bit of an hybrid between the VBE’s Project Explorer and Object Browser windows – we see all the members of every module, and we can double-click navigate anywhere.

We’re planning to implement a number of refactorings in 1.3, and some of them are going to be available from the Code Explorer‘s context menu. 1.3 will also integrate GitHub source control, and the Code Explorer‘s context menu will be usable to commit or undo changes to a specific file – importing and exporting files is also going to be in that menu by then.

What else would you use the Code Explorer for? Does the Code Explorer replace the VBE’s Project Explorer for you?

Version 1.2 will hit hard!

Rubberduck has had a decent unit testing feature since 1.0. Version 1.1 introduced a concept of code inspections – a proof of concept really, a sketch of a vision of what we wanted Rubberduck to do with the VBA code in the IDE.

Upcoming version 1.2 has undergone massive changes in the parsing strategy – going from a home-made regex-based solution to a full-blown ANTLR [slightly modified] Visual Basic 6.0 grammar generating a lexer and parser. As a result, code inspection capabilities have gone exactly where we envisioned them from the start.

Here’s what version 1.2 can find in your VBA code (in alphabetical order):

  • Implicit ByRef parameter
  • Implicit Variant return type (function/property get)
  • Multiple declarations in single instruction
  • Function return value not assigned
  • Obsolete Call statement
  • Obsolete Rem statement
  • Obsolete Global declaration
  • Obsolete Let statement
  • Obsolete type hint
  • Option Base 1 is potentially confusing
  • Option Explicit is not specified
  • Parameter can be passed by value
  • Parameter is not used
  • Variable is never assigned
  • Variable is never used
  • Variable type is implicitly Variant

And we have more on their way! …and that’s just code inspections.

Version 1.2 also introduces a Refactor menu, which allows extracting a method out of any valid selection – and future versions will allow inlining a method into its call sites, renaming any identifier (and updating its usages), reording/removing parameters from a signature (and updating usages), promoting a local variable to module-level, or extracting a whole interface out of a class module’s members… and more.

Version 1.2 also introduces an API for VBA code to integrate with GitHub source control, through the very same technology that allows Visual Studio 2013 to integrate with GitHub, using LibGit2Sharp. At this stage it’s pretty much what code inspections were in version 1.1: a proof of concept – but in future versions, expect to be able to manage source control for your VBA projects in a way similar to how you manage source control for your .NET projects – within the IDE itself!

Rubberduck 1.2 will hit hard… and our duck is still but a little duckling: VBA will never be the same when it grows all its, uh, rubber.