Edit and Continue: useful tool or disaster in waiting?

• By Mike Gunderloy
• October 21, 2004

Microsoft recently announced that Edit and Continue is coming to C# in Visual Studio 2005. We already knew that the feature, prominent in Visual Basic before the advent of .NET, would be in VB in that version as well. Despite the fact that this was a widely-requested feature, there's been some negative feedback over this decision. Let's take a look at the pros and cons.

If you've never used an IDE that enables Edit and Continue, you might be a bit hazy over how it works. The basic idea is pretty simple: when you break into the debugger, you can do more than just inspect the current values of program data and see where you are in the code. You can also alter data or even change code, and then flip back from debug mode to run mode. At that point, the application continues executing - but with your new code, not the originally-compiled code. For more details about how this will be implemented in C#, see Using the Edit and Continue Feature in C# 2.0.

Many people who've used Edit and Continue are enthusiastically in favor of it. The basic argument is that you can't write perfect code, so you'll inevitably end up doing some debugging. When you do have debugging to do, Edit and Continue lets you make a fix and check that it works without needing to go through an entire compile-and-run cycle, possibly with many steps involved to get back to the failure point.

Another school of thought sees Edit and Continue as a crutch that encourages sloppy programming habits. These folks say that with proper unit tests you should never have to explore in your code to find a failure, and that making changes while debugging is undisciplined and liable to leave your code in worse shape than it started. Proper application of test-driven development, they argue, makes Edit and Continue both superfluous and dangerous.

While I can understand the arguments of both sides, I must admit that my own sympathies lie mostly with those who find Edit and Continue to be a useful addition to the development environment. In part, this may reflect my own history as a VB developer, but I think it also says something about my overall attitude towards software tools. I just don't believe that you can look at a tool like Edit and Continue, or test-driven development, or outlining in the IDE, and pronounce it uniformly "good" or "bad." If a particular tool doesn't fit in with your own method of creating code, don't use it. That's no reason to prevent other people from using it.

Yes, Edit and Continue can be misued to write sloppy code that's not adequately tested. But so can many other things. It can also be a big help in appropriate situations. Rather than get into a shouting match over whether it's a good feature or a bad one, we'd all be better off learning when and how to use it productively, and when to complement it with other techniques.