Does Microsoft Understand Refactoring?

Microsoft is bringing refactoring support to Visual Studio .NET with the next release (code-named "Whidbey"). Well, sort of. At the PDC this year, they demonstrated some refactoring support in C#. Right-clicking in C# code gives you a Refactor shortcut menu item with choices including Extract Method, Encapsulate Field, Extract Interface, Surround With, Insert Expansion, Rename, and Change Method Signature. "Insert Expansion" puts in code blocks for things like property definitions or For Each loops, while "Surround With" can stack if/then/else, try/catch, and other constructs around the selected code.

There's no refactoring support in VB .NET in the PDC build of "Whidbey." But Paul Vick, Technical Lead on the VB .NET team, has indicated in his weblog that VB will be getting at least some of these capabilities. They won't be grouped under the name of refactoring, though. Vick points out that even many experienced and intelligent developers haven't run across the term "refactoring," and suggests that it would be better not to make people deal with the term to use the features.

Visual C++ doesn't appear to have refactoring support in the PDC build of "Whidbey" either. I haven't seen any statement from Microsoft about whether it's coming or not, so I'll focus on the VB .NET and C# support here. That support gives me concern on several levels.

First, I really don't understand the decision to avoid the term "refactoring" in VB .NET. Sure, there will be some (even many) VB developers who haven't run across the term before. But is that any reason to protect them from it now? Suppose the same thinking had been in place when object-oriented programming started to creep into VB 4? "Oh, let's not call them classes; VB developers don't have time to figure that term out. Let's call them boxes instead." Imagine the difficulty that VB developers would have had in communicating with the rest of the development world.

I think the way that classes were introduced into VB provides a pretty good example of how refactoring could be introduced: don't try to hide or rename the concept. Instead, use the same term as the rest of the industry and provide help content to make it understandable by VB developers who haven't run across it before. We know that the VB help team can do a good job when they're given the resources; I have no doubt that they could produce a great guide to refactoring, when to use it, its pitfalls, and the joys of test-driven development.

I've got a different concern with the C# implementation of refactoring: that menu item includes a bunch of things that are not refactorings. The term was defined quite precisely by Martin Fowler in his book Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999):

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

Here's my problem: the "Insert Expansion" and "Surround With" pseudo-refactorings are practically guaranteed to change the external behavior of the code. Refactoring, as practiced developers who embrace test-driven development, involves making changes to code that don't affect its ability to pass the current set of unit tests. Refactoring is a disciplined process, not a code-name for "fast ways to write more code." By including non-refactorings on the Refactoring menu, Microsoft is inevitably going to dilute the term and destroy its precision.

So, for one group of developers, Microsoft is going to pretend the term "refactoring" doesn't even exist. For another, it's going to use a well-defined term in an ill-defined way. Both of these moves will make it hard for Microsoft-oriented developers to talk to developers in the rest of the industry about refactoring. Java developers using IntelliJ IDEA, for example, benefit from a huge catalog of actual refactorings integrated into their IDE. Microsoft could do worse than to copy that implementation.

Finally, although it makes sense to me that the two languages should be different, I am dismayed to see the IDE support continuing to diverge for VB .NET and C# developers. Microsoft apparently feels that C# developers want one thing from their IDE, and VB .NET developers want another. I can't be the only developer who moves back and forth, can I? After watching Microsoft invest immense resources in moving all of their development tools into the same IDE over the past several years, it's perplexing to see them allowing that IDE to immediately devolve into separate tools for separate languages.

Of course, there are undoubtedly people working at Microsoft who understand refactoring thoroughly and deeply. It's not like there's an official Microsoft stance on the topic of refactoring. But it bothers me to see the Visual Studio .NET team, and its client language teams, adding such confusing and watered-down support for what could be a major productivity and code quality improvement if it were done right.


Upcoming Events


Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.