Answer Ron's questions about C# Refactorings.
On the Yahoo! Groups Refactoring DL, Ron Jeffries asked some questions about Visual C# 2005 Refactorings.
"Can you say how you expect the Microsoft refactorings to stack up against the existing ones that are out there?"
I've personally spent very little time exploring the C# and Java Refactoring tools out there. Most of what I know is from the competitive analysis efforts of the PMs on the team, and what I read on this group. I keep meaning to get some first-hand experience with them, but never find the time. (Too busy reading Ron's book!)
The most obvious difference will be that the Refactoring menu in Visual Studio will be quite a bit shorter than the others. We decided to focus on making a smaller set of higher quality Refactorings.
The other big difference is that our Refactorings are very good at giving you reliably correct results. It is our goal that when applied to a legal C# program, you can be sure that your code will maintain its behavior.
The build on this laptop has 7 Refactorings:
These two are by far the most important that we built. They rank very high on “difficulty to do by hand” and “value to your code”.
- Reorder parameters
- Remove parameters
- Promote Local Variable to parameter
These three together are “change method signature”. These aren’t nearly as important for your code as Rename & Extract Method, but they can be quite hard to do by hand. Note that Add Parameter is missing. Promote Local takes its place, providing a more code-focused experience.
This was easy to build on top of the technology that provides Rename, and it leverages C#’s properties so we can say we’re cooler than that other language. You can get by without it in a few steps including a Rename, so it doesn’t rank so well on the “hard to do by hand” scale.
As we read through the Fowler list, this one seemed simple to do, so we did it. However, it’s not something you need to use very often, so I’m not sure I’d choose if I had to do it over. Perhaps I would have selected a streamlined Push Up Method instead, which could fill the same needs and others.
One of the themes we picked up on part-way through is that there’s value in building smaller, simpler Refactorings, and letting users compose them at will.
We can build them with a simpler UI. Instead of a bunch of options, you get to select which Refactorings to apply when. For example, Promote Local doesn’t provide any flexibility about where in the list to insert the new parameter; it always inserts at the start of the list. We expect that you’ll use Reorder Parameters to get the results you want.
“Is there any plan to make refactoring support pluggable, or otherwise to improve the ability of normal humans to generate code?”
We don’t intend to build Refactoring extensibility into this product. Bummer, huh? I hope we can get to it soon, though; it's clearly important.
One of the features we did build is “Generate Method Stub”, where we will take a call to a method that doesn’t exist & generate a stub that matches. It’s great for TDD & Programming by Intention.
