On this page... (hide)
Refactoring in VB6
http://www.oreillynet.com/ruby/blog/2006/03/transformation.html - steve Yegge article; starts out talking about Ruby, ends up saying “It’s not about the automation, stupid!”
It is not uncommon for people ranging from the CEO to managers to HTML grunts to object to the concept of refactoring. The concern is expressed in many ways, but it usually amounts to this:
We don’t have the time to waste on cleaning up the code. We have to get this feature implemented now!
There are two possible responses to this comment. The first is that refactoring saves time in the long run. The second is that you have more time than you think you do. Both are true.
Refactoring saves time in the long run, and often in the short run because clean code is easier to fix and easier to maintain. It is easier to build on bedrock than quicksand. It is much easier to find bugs in clean code than in opaque code. In fact, when the source of a bug doesn’t jump out at me, I usually begin to refactor until it does. The process of refactoring changes both the code itself and my view of the code. Refactoring can move my eyes into new places, and allow me to see old code in ways I didn’t see it before
- What is Refactoring?
- Why Should You Refactor?
- What Does Refactoring Look Like?
- Isn’t This Just Relocating the Complexity?
- When Do You Refactor?
- 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.
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
- above excerpted from http://www.codeshine.com/CodeShine/default.htm
- Unfortunately, the product does not work within the InputAccel nor FormWare VBAs.
No comments yet.