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