Tag: vba

Naming is hard. Renaming is easy.

Rubberduck VBALeave a comment

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

How many VBA modules declare variables looking like this:

Dim v As Long, vWSs As Variant, Mrange As Range, Vrange As Range

Or like this:

Dim i As Long
Dim LR As Long

How many procedures have cryptic names that only the author knows what they mean?

How many Times did you refrain from renaming a procedure in fear of breaking the code?

Fear no more. Renaming doesn’t have to be the hardest part of using meaningful names in code.

With the next release of Rubberduck, finding a meaningful name is going to be the hardest part – I’m please to announce that Rubberduck 1.3 will feature a rename refactoring:

rename-const

Awesome. How does it work?

I’m tempted to say “Magic!” here. Rubberduck uses the current selection (/caret location) to guess what you’re trying to rename. If you’re on a constant usage, it knows to rename the constant and every single one of its references; if you’re just inside a procedure scope, it guesses you want to rename the procedure and affect every single call site; if you’re somewhere in the declarations section of a module, it lets you rename the module itself, and automatically adjusts every explicit reference to it.

The Rubberduck/Refactor menu will feature a new “Rename” button, accessible with Alt+B,R,R (Rubberduck/Refactor/Rename).

The Code Explorer‘s context menu will also feature a “Rename” button, so that any module/member can be renamed without even looking at the actual code.

Lastly, we’ll hijack the code pane context menu and add our “Refactor” menu in there, too.

Naming is hard. Renaming doesn’t have to be!

Rubberduck 1.3: When the VBE becomes a real IDE

Rubberduck VBA3 Comments

Parsing is hard!

Rubberduck parsing is being refined again. The first few releases used a hand-made, regex-based parser. That was not only unmaintainable and crippled with bugs, it also had fairly limited capabilities – sure we could locate procedures, variables, parameters… but the task was daunting and, honestly, unachievable.

Version 1.2 changed everything. We ditched the regex solution and introduced a dependency on ANTLR4 for C#, using an admittedly buggy grammar intended for parsing VB6 code. Still, the generated lexer/parser was well beyond anything we could have done with regular expressions, and we could implement code inspections that wouldn’t have been possible otherwise. That was awesome… but then new flaws emerged as we realized we needed more than that.

Version 1.3 will change everything again. Oh, we’re still using ANTLR and a (now modified) buggy grammar definition, but then we’re no longer going to be walking the parse tree all the time – we’re walking it once to collect all declarations, and then once to collect all usages of every single identifier we can find.

What does that mean?

Imagine a table where, for every declaration, you lay down information such as the code module where you found it, the exact location in the code file, the scope it’s in, whether it’s a class module, a standard module, a procedure, a function, a property get/let/setter, an event, a parameter, a local variable, a global constant, etc. – and then whether it has a return/declared type, what that type is, whether it’s assigned a reference upon declaration (“As New”) – basically, on that table lays the entire code’s wireframe.

Then imagine that, for everything on that table, you’re able to locate every single reference to that identifier, whether it’s an assignment, and exactly where that reference is located – at which position in which code file and in which scope.

The result is the ability to make the difference between an array index assignment and a function call. If VBA can figure out the code, so can Rubberduck.

This means the next few versions will start seeing very cool features such as…

  • Find all references – from a context menu in the Code Explorer tree view, or heck, why not from a context menu in the code pane itself!
  • GoTo implementations – easily navigate to all classes that implement a specific interface you’ve written.
  • GoTo anything – type an identifier name in a box, and instantly navigate to its declaration… wherever that is.
  • Safe delete – remove an identifier (or module/class) only if it’s not used anywhere; and if it’s used somewhere, navigate to that usage and fix it before breaking the code.
  • Rename refactoring – rename foo to bar, and only the “foo” you mean to rename; this isn’t a Find & Replace, not even a RegEx search – it’s a full-fledged “rename” refactoring à la Visual Studio!

Not to mention everything else that’s in store for v1.3 (did I say IDE-Integrated GitHub Source Control?) – stay tuned!

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

Rubberduck VBA3 Comments

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?

Overcoming Limitations: Testing that an event was raised

Rubberduck VBALeave a comment

Why?

Rubberduck unit tests live in standard modules (.bas) for a reason: they are executed with Application.Run, which is meant to execute macros. In an ideal world, Rubberduck unit tests would live in class modules (.cls) and be executed with CallByName. The problem is that CallByName is a VBA function, not an API member – and we can’t just execute arbitrary VBA code magically, so until that’s figured out, we have a little bit of a limitation here.

On top of that, not all Office applications feature an Application.Run method, which means Rubberduck unit tests can’t work in, say, Outlook.

It also means Rubberduck unit tests can’t declare a WithEvents object variable, because like the Implements keyword, that keyword is reserved for use in class modules.

Now, what?

So if one has a class with a method that raises an event, a test that would ensure the event is raised with the expected parameters, needs to take a little detour.

Say we have MyClass looking like this:

Option Explicit
Public Event Foo(ByVal value As String)

Public Sub DoSomething(ByVal value As String)
 RaiseEvent Foo(value)
End Sub

We will want to write a test to verify that DoSomething raises event Foo with the specified value argument.

TestHelper class

First step is to declare a WithEvents object variable to handle the event. Since that can only be done in a class module, we’ll need a new class module – call it TestHelper.

Option Explicit
Private WithEvents sut As MyClass
Private RaisedCount As Long
Private LastValue As String

Public Property Get SystemUnderTest() As MyClass
 Set SystemUnderTest = sut
End Property

Public Property Set SystemUnderTest(ByVal value As MyClass)
 Set sut = value
End Property

Public Property Get HasRaisedEvent() As Boolean
 RaisedCount > 0
End Property

Public Property Get Count() As Long
 Count = RaisedCount
End Property

Public Property Get LastEventArg() As String
 LastEventArg = LastValue
End Property

Private Sub sut_Foo(ByVal value As String)
 RaisedCount = RaisedCount + 1
 LastValue = value
End Sub

Now that we have encapsulated the knowledge of whether and how our event was raised, we’re ready to write a test for it.

TestMethod

'@TestMethod
Public Sub TestMethod1() 'TODO: Rename test
 On Error GoTo TestFail
 
 'Arrange:
 Dim sut As New MyClass
 Dim helper As New TestHelper
 Set helper.SystemUnderTest = sut
 
 Const expected As String = "foo"
 
 'Act:
 sut.DoSomething expected

'Assert:
 Assert.IsTrue helper.HasRaisedEvent
 Assert.AreEqual expected, helper.LastEventArg

TestExit:
 Exit Sub

TestFail:
 Assert.Fail "Test raised an error: #" & Err.Number & " - " & Err.Description
End Sub

This test will pass as is, and will fail when the tested method’s logic changes:

Public Sub DoSomething(ByVal value As String)
 RaiseEvent Foo(value & "A")
End Sub

test-failed

Until we figure out a way to move Rubberduck unit tests to class modules and run them with CallByName, using a helper class will be the only way to test event raising.

Version 1.2 will hit hard!

Rubberduck VBA1 Comment

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.