Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring (from


Wikipedia:Refactoring - alpha list
Refactoring in VB6 - steve Yegge article; starts out talking about Ruby, ends up saying “It’s not about the automation, stupid!”


Overcoming Objections

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



DotNet Code Refactoring - C#




  • What is Refactoring?
  • Why Should You Refactor?
  • What Does Refactoring Look Like?
  • Isn’t This Just Relocating the Complexity?
  • When Do You Refactor?


What is Refactoring?

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.”


Why Should You Refactor?

  1. 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.
  2. 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!


What Does Refactoring Look Like?

Refactoring usually consists of a series of small steps that gradually transform complex-seeming code into more readable, better-encapsulated code.


Isn’t This Just Relocating the Complexity?

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.


When Do You Refactor?

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




See Also




Category tags

Refactoring Productivity Programming Debug



No comments yet.



Add Comment

 Your Message
 Enter value ← Have you entered the code number?