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.