What is "refactoring" anyway? It's actually different things to different people. In this article, we will look at five tools that can be used for refactoring to see what the differences are. And just to show that I haven't given up on VB 6 (like Microsoft has), the first four can be used for VB 6!
The "mainstream" definition of refactoring can be found in Martin Fowler's book, Refactoring:
"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence, when you refactor you are improving the design of the code after it has been written."
(Thanks to Warren Sirota's CodeShine web page for this quote. Martin Fowler also maintains a web page focused on refactoring at this link.)
But it's easier to define refactoring than to actually do it. Most refactoring is done by what has been called Biological Development Units (BDU's). In other words, "programmers". The main reason is that it's just as hard, or maybe even harder, to "improve the internal structure" of a program as it is to write it in the first place. The question does come up, "Why didn't the original programmer structure the code differently?" And, very often, the answer is, "Because it doesn't work that way." ... for some very subtle reason that you never suspected.
The first "golden rule" in refactoring is "Test! Test! Test!" And when you have done that, "Test some more." The last thing you want to do is "improve" a program by breaking it. The second rule is, "Back up your code before you change it!" The wrong time to find out that you have introduced a new bug is after you have made changes that you can't undo.
Most of the tools reviewed here can be used with VB 6. There is still a lot of VB 6 code out there and it's still a good development environment ... if you have the VB 6 compiler available to you. (Microsoft won't sell it anymore.) As Warren Sirota -- the author of the CodeShine tool -- writes:
"There is a tremendous amount of legacy code lying around, and not every application is worth rewriting. I have a client with a simply huge commercial VB6 app, for instance. Selling him on giving me umpteen thousand dollars to move it to .NET, with the only benefits being 'better structured code, more OO, possibly lower maintenance costs way down the road', is simply not going to happen until VB6 apps no longer run under Windows - and we know that VB 6 apps run under Vista, so that will be a long time."