I’ve been fairly absent from this blog lately. I’ve been busy working on a new release of Rubberduck and, honestly, there are only so many hours in a day. More importantly, there are only so many concentrated thoughts to go around in 24 hours. So, I apologize for being gone for so long. I hope you can forgive me when you see the results. I’m really excited about our next release. There’s some really awesome things in there. You can download the pre-release now if you’re interested. There are a few kinks to work out, but things should be stable very soon.
To be truthful though, that project is the last thing I want to talk about right now. Rubberduck has become an obsession. There have been so many early mornings and late nights that I can’t possibly count them. There will be more. Many more. We’re only getting warmed up… and I’m going to talk about it anyway. It is an obsession after all. Like any addict, I just can’t let it go.
That’s okay though. Projects don’t succeed unless two things happen.
- There’s a problem to be solved.
- Someone becomes obsessed with solving that problem.
Friends, let me tell you, the VBA Editor has some problems. It’s not seen a single update since… I don’t know if it’s ever seen an update actually. The language itself saw an upgrade to accommodate 64 bit integers, but other than that, things have been the same for a very long time.
I was reading over the checklists from Code Complete recently and I noticed the section about Programming Tools. It didn’t take me long at all to realize that we had independently perceived the same important features of an IDE that Steven McConnel knew in 1993.
Do you have an effective IDE?
Does your IDE support outline view of your program; jumping to definitions of classes, routines, and variables; source code formatting; brace matching or begin-end matching; multiple file string search and replace; convenient compilation; and integrated debugging?
Enter the Code Explorer.
Do you have tools that automate common refactorings?
Enter the Extract Method refactoring.
Are you using version control to manage source code, content, requirements, designs, project plans,and other project artifacts.
We’re planning on including Git Integration with the IDE and have already exposed an API to make it easier to put your VBA projects in a Git repository in the meantime.
If you’re working on a very large project, are you using a data dictionary or some other central repository that contains authoritative descriptions of each class used in the system?
We’re planning on re-instating the ability to modify Class/Procedure descriptions through the editor. (VBA lost this feature when it come over from VB6 and Visual Studio.)
Are you making use of an interactive debugger?
Okay, so the VBE does this pretty well actually.
Does your test environment include an automated test framework, automated test generators, coverage monitors, system perturbers, diff tools, and defect tracking software?
This whole thing started because we wanted to able to test our VBA Code. We don’t have test generators or coverage monitors (yet, this list has me considering it now), but simply adding an integrated testing framework is a huge step in the right direction.
Overall, does your environment benefit from adequate tool support?
Obviously it does not, or we wouldn’t have had to build so much of this ourselves.
Maybe part of the reason so many developers scoff at VBA as a solution is the lack of these critical tools. You know what? I don’t blame them. I get it. The VBE sucks, but it and VBA aren’t going any where any time soon either. So, instead of scoffing about it, let’s fix it. Let’s build a better tool. Isn’t that what we programmers do best anyway?