 CodeShine™
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.
To visit the brand-new CodeShine discussion group and talk about any VB6 or
CodeShine refactoring concept,
click here.
Refactoring
Benefits - NEW
What is Refactoring?
Why Should You Refactor?
What Does Refactoring Look Like?
So What?
Isn't This Just Relocating
the Complexity?
When Do You Refactor?
What's in CodeShine?
System Requirements
According to Martin Fowler, in his excellent
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."
(by the way: I highly recommended this book to anyone
interested in seeing excellent examples of Object-Oriented design principles
in action. Even though the examples are in Java, they should all be readable
to the Visual Basic programmer who knows even a little bit about creating
classes. I used to think that good code looked like maybe 20- or 30-line
routines with a lot of comments. After reading Fowler, I now shoot for
5-line routines with no need for comments, because the method calls are so
well-named they're self-explanatory. Don't always get there, but I'm close
much of the time)
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.
- Code quality tends to degrade over time. A
little patch here, a larger patch there, and pretty soon the patches get
harder and harder to make, and the code gets harder and harder to
understand. A refactoring tool like CodeShine lets you improve the
quality of your code virtually every
time you look at it, with almost no effort, and with total confidence.
- When you're debugging or enhancing code
that you wrote a few months ago, or, worst luck :-), "someone else's code", the first
task is to understand it. Refactoring helps you to do this and to
permanently "bake" your understanding right into the code, in an easy and painless
manner. Take pity on your later self (/selves) - refactor as you debug, test
and/or review code!
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.
Click here to go straight to the examples.
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).
Extract
Function a variant on
Introduce
Explaining Variable that makes the calculation available throughout the
module.
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.
- Visual Basic 6
- Any Office 2000 or higher application
| 
