With last week's announcement that Edit and Continue would be supported for C# in VS 2005, there was an initial cry of 'hallelujah' from many developer blogs. I've opted not to link to any for fear of having someone feel singled out, but in my aggregator this past weekend, I must have browsed past a couple dozen posts about how great this announcement was.

Now that a few days have passed, reality sets in and a few different voices have stepped up to suggest that E&C isn't a silver bullet for developers. It's interesting to watch the reactions play out in the blog posts, which usually go like this:

.NET VoR (Voice of Reason): Edit and Continue makes it to easy to screw things up and get sloppy with your development. You should be taking a reasoned approach to your debugging, use unit tests to confirm your approach, and not fix bugs based on a specific condition that exists at that particular runtime.

.NET E&CE (Edit & Continue Evangelist): Just because it's possible to screw up with E&C doesn't mean it should be pulled out! Would you also suggest that [insert analogy of tool mis-use here]?!

I guess what I find interesting about it is that the E&C evangelist types seem to think it's an all or nothing proposition. Unless I've missed it, none of the people arguing against E&C are suggesting that it should completely be removed from the product. Rather, they're suggesting that it should be used with great care because of the ability to fix bugs with small, one-off fixes in code instead of shutting down the debugger and fully thinking through the problem.

I recall Juval Lowy talking about this on .NET Rocks at some point last year (probably around the PDC when it was announced for VB.NET). His comment was along the lines of E&C being somewhat incompatible with the "C# personality". That personality, which often comes to C# via C++ or Java and tends to be component-focused, is different than the VB.NET personality, which comes from a more RAD place and tends to be more app-focused. As he put it, when the C# personality is faced with a bug, (paraphrasing) "they lean back in their chair, stare at the ceiling, go get some coffee, ponder a solution, and THEN they lean forward to hit F10 and move to the next line." :) For those people, E&C isn't as attractive as other features that focus more on code quality, profiling, performance, and so on.

Sure, it's great that you can fix things like a typo in a string literal or some other no-brainer quick fix. But bugs that involve an application's logic or workflow aren't the type of thing that should be fixed while sitting on a breakpoint at runtime.

It's also worth noting that the inclusion of E&C is a good example of Microsoft's newfound community awareness and desire to work closely with its developer customers. No question -- it shows responsiveness.

I guess the two thoughts that come to mind for me in all of this are:

• E&C can be handy in some scenarios -- but it's not a panacea, it can be easily misused, and I think few would argue that its use is a "best practice" for professional developers. My hope is that the .NET developer community comes up with some collective guidelines or general agreement on where/how it makes sense to use or avoid E&C.
• I also hope that many of the other things that are being worked on for the 2005 release aren't scaled back because of the work on E&C. Even Microsoft has limited resources and time when it comes to development. Sam Gentile's post about refactorings being missing is a good point -- let's hope that the inclusion of E&C doesn't come at the expense of refactorings or other features that do promote best practices.