Refactoring

  • Article

If you’ve seen the PDC prerelease of Visual Studio (codename Whidbey), you may have noticed the new “Refactoring” menu when editing C# code. 

 

There are 3 criteria we use to select refactorings to implement Whdibey:

 

  • Importance of the Refactoring.  Some refactorings contribute more to the clarity of code than others.
  • Difficulty of doing the Refactoring by hand.
  • Difficulty of implementing the Refactoring in a tool. 

 

The First Tier

 

In my experience with Refactoring, there are two Refactorings that stand out as being more important in a tool than others:

 

RenameMethod

  • Getting the names of things right adds a lot to clarity. 
  • Knowing that I can change a name later removes a barrier to creating an entity now.  (I’ll create a class, method, or variable now, and figure out what to call it later)
  • Finding the references to ambiguous names is sometimes very hard.  Search/replace across files often doesn’t cut it when dealing with overloaded methods, types in different namespaces, etc.

BTW, I don’t expect users to think of RenameMethod, RenameClass, RenameField, etc. as being different things.  There’s just Rename.  Some of the knobs to turn are a bit different, and the internal workings may be different, but it’s not really important from a user’s perspective.

ExtractMethod

  • Developers often recognize the need to perform ExtractMethod in their code, but don’t do it because of the tedium involved.  By providing it in a tool, you’re much more likely to perform this very important Refactoring.
  • Sometimes figuring out the exact inputs & outputs to a method is tricky.  If you have a tool, it saves you a bunch of hassle.
  • If you extract a method early, you’re more likely to call it later instead of duplicating code.
  • If a class has a bunch of small methods, it becomes easier to see when & how to refactor to a new class.

 

Note that except for the last bullet, none of this helps you do Object Oriented programming any better.  I want to talk about that more; maybe in another blog entry.

 

Experiences with Rename

 

Rename is pretty transparent – you know what it is, and what it does.  But as I mentioned, it’s nice that can create a new class right away without having to worry about picking the right name.  I know I can always fix it later.  Sometimes that name becomes obvious after the class is coded & I can see its members. 

 

Sometimes (this is neat) I’ll rename to what I think is the correct name, but when I see it in context I realize it is wrong.  Then, with the actual usage in mind, I can rename again to something better.

 

If your spelling isn’t very good, you can code up what you want now & fix it later.  No need to stop & consult a spell checker.  (Or, if you’re me, you can fix other people’s spelling)

 

Experiences with Extract Method

 

Extract Method is a wonderful luxury.  It does a bunch of analysis to figure out what to pass, so I don’t have to.  I just select some code & go.

 

In the Refactoring book, Fowler lists comments as a smell – if you have a comment, it indicates that some code is not as clear as it could be, and could benefit from Refactoring.  I’ve seen people try to understand code by commenting it as they read & comprehend. 

 

When I’m trying to understand a complex bit of code, I use ExtractMethod.  I select a statement or block that is contributing to the complexity and give it a name by extracting it.  After a few iterations, a complex function quickly becomes a simple one that reads like English.  It’s nice.

Comments

  • Anonymous
    December 04, 2003
    How stable is whidbey?

    I used previous beta versions of Visual Studio .NET. The last one was 2003 beta 2, which I used for writing production code.... I'm wondering when it will be 'good enough' for me to trust it for day-to-day use (in my case writing Windows Forms programs).
  • Anonymous
    December 05, 2003
    Bukit,

    I don't think I should endorse or discourage use of Whidbey here. That's a question for marketing folks to answer. Just remember that Whidbey is not a beta, it's a preview.

    All of us here use Whidbey for all our day-to-day development, and have since the early part of the product cycle. We call this practice "eating our own dog food" or "dogfooding", and think it's an important part of getting the polish & stability users expect.
  • Anonymous
    February 02, 2004
    I'm hoping that we'll get the refactoring menu for VB as well as C#. Long ago, I actually brought up the idea of adding refactoring to the IDE in a User Group meeting in Denver, where the C# lead (product manager?) was seeking input.

    I use both C# and VB, but I think it's important to give everyone the best tools they can use.

    Will the refactoring menu be on VB, too?
  • Anonymous
    April 15, 2004
    If I rename a class that is already checked into SourceSafe, will this refactoring capability handle renaming the file in SourceSafe and keeping the file's history?
  • Anonymous
    April 16, 2004
    All our refactorings correctly interact with integrated source control, checking out the files as appropriate.