THE refactoring add-in for Microsoft Visual Basic 6 (VB6). It brings one of the most important features of the most state-of-the-art development systems to good old classic VB6.
Refactoring is a tremendous aid in clarifying code as you debug it, and as you write it.
Refactoring Benefits - NEW
According to Martin Fowler, in his excellent book, Refactoring:
In my programming practice, I interpret "refactoring" a little more loosely than Mr. Fowler - I often refactor while debugging, so the purpose of the refactoring is not always to leave the external behavior unchanged. Each individual refactoring will leave the external behavior alone (which is what makes it safe), but I use it to isolate and/or clarify a piece of behavior so that it can be reused by other code or extended. In other words, the refactoring doesn't change the behavior, but can be used as one step in a process whose goal is to change behavior.
Refactoring usually consists of a series of small steps that gradually transform complex-seeming code into more readable, better-encapsulated code.
A few examples are included in the online CodeShine help system.
If you like, you can see this and a couple of other refactorings in action by clicking here to view a Flash animation. Or, simply download and install the 21-day trial version of CodeShine and try it for yourself.
If you've examined the examples, perhaps you are saying to yourself, "So what? I could have accomplished all that with cut-and-paste and renaming." Of course, you could have done that. But cut-and-paste doesn't automatically do the parameter analysis the CodeShine does, so you'd have to really think about that in many cases. And, aside from that fact that cut-and-paste is slower and more cumbersome than using CodeShine, it is also more error-prone. Suppose you didn't realize that you needed to pass parameters to the extracted method? Then you have to add a few cycles of compile, get error, fix to your process. Suppose the code you extracted manually contained custom error handling or an Exit Sub that you didn't notice? You could have moved it and introduced a bug, whereas CodeShine would have warned you. Suppose you just were a bit too lazy to go to the trouble of doing all that cutting and pasting and parameter checking - then your code would still be ugly and not as readable.
When refactoring is really easy and really reliable, then you will do a lot more of it. It's only natural.
To a certain extent, it is! But relocating the complexity to improve readability at a high level can be a worthwhile thing. Also, because variables are moved into smaller, single-purpose code blocks, encapsulation is improved.
You won't waste time going through all your existing code with a fine tooth comb refactoring just to improve the esthetics. But you will inevitably read through existing code as you try to fix or enhance it. And you will look at a block of code and say, "just what is this piece doing?" And you'll figure it out. But if you had to ask the question, that's a sign that it's not that well-structured. You could simply add a comment in front of the code as an aid to your future self or the other unfortunates who will inherit the maintenance of that code, but (a) it's not always clear what the scope of a comment is; i.e., exactly how much of the following code does it apply to, and (b) adding a comment does not improve the encapsulation of the existing code. You're usually better off selecting that code, using Extract Method (or another refactoring), and, instead of adding a comment, giving the new routine a name so descriptive that it functions as a comment.
Extract Method is, in this author's opinion, the most powerful and useful of refactorings. It allows you to highlight a block of code and turn it into a new Sub or Function. It deduces which parameters are needed by the new method in order to compile properly, and builds the appropriate Sub or Function declaration line, as well as the proper calling line in the original routine. It does this in a thorough way that can save a lot of time dealing with the compile errors and other complications that would occur if you just did this through cut-and-paste. CodeShine's implementation gives you some very useful customization options.
Introduce Explaining Variable takes the selected expression and substitutes a new variable for it. This function includes inserting a declaration for the variable, assigning the value to the variable, and substituting the variable for the expression in the selection. This is a very handy little utility - if you're writing expressions that are a bit too complex to be easily readable, this can help simplify the code (especially useful for improving the readability of complex condition clauses in if <condition> then statements).
Localize Module Variables - this is extremely useful when you have a complicated module to debug - it takes all the module-level variables and analyzes their usage. You can automatically convert module-level variables to local variables and delete unreferenced module-level variables.
Rename lets you easily rename any local, parameter, or private module-level variable, function or sub. It avoids many of the errors that can occur when doing a simple find-and-replace to change a variable name.