Edit and Continue: useful tool or disaster in waiting?
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
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.
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.