Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

I have been following the Edit and Continue debate over the last few years and although I understand the arguments of the proponents, I have to admit that I am still of the opinion that it is not a feature that .NET needs. In this article, I'll try and give both sides of the argument and let you decide.

At the PDC last year, Microsoft announced that Edit and Continue (EnC) will return to VB.NET in the next version of .NET (codenamed Whidbey). This finally resolves an issue that has concerned VB.NET developers since .NET was first released. Edit and Continue is a feature that native code ("Classic) Visual Basic developers have been using for years. The idea is that during a debugging session, a VB programmer could identify a bug in the code and correct it. Then, while still in the debug session, with the same application state, the developer can single step to the next line. If the next line is the line that the developer has changed, then it will be the new code that is executed rather than the old code. So under the covers, the compiler will have recompiled the code and the debugger will have attached to the new version. It's all very clever technology.

EnC is really suited to scripting languages where lines are compiled as they are reached. I guess this is the origin of EnC: For several iterations, VB was essentially a tokenized scripting language. Even when VB Classic got a real compiler, VB developers could still use EnC, perhaps because the feature was so widely used. However, when VB.NET emerged, EnC was not one of the features carried over from VB Classic.

I do not have access to the original design documents for .NET, but I suspect that EnC was not a feature that was considered to be important to .NET. Indeed, in talking with some Microsoft developers, it appears that adding EnC to Whidbey was not a trivial task, and significant changes had to be made to the runtime to support this feature. I am all for improving the runtime, but I get a little wary when changes are made for no apparent and compelling reason.

My own experience with EnC comes from unmanaged Visual C++. Version 6 gained EnC, and I used it exactly once before consigning it to the list of features that simply did not fit in with the way that I worked. You see, I take a structured attitude to programming, which I developed when I worked for a company that was keen to achieve ISO 9000 certification. I found that company's software-development procedures very restrictive, but in the long term I recognize that they helped to produce high-quality code. I see EnC as being the antithesis of those procedures.

One of the justifications I have heard for using EnC is that a bug may appear a long way down in the call stack and it may take a long while to get to that point using the debugger. The argument goes that a large amount of time will be lost if the developer has to stop the process, edit, recompile, and restart. I would accept that this is the case when a developer goes into "fire fighting mode-that is, to try and fix a bug at a client's site as quickly as possible-but even then I would grumble that if the code had been properly tested, the bug would not have existed. However, when code is being developed in a software house, I see no justification for EnC. My argument is that proper testing during development should be more effective at eliminating bugs.

Further, I view bugs as being significant issues and fixing a bug is not as simple as changing the code. (As an aside, one company I worked for employed a consultant to fix some bugs in their code. It was only after the consultant had left that it was discovered that he had simply commented out all the calls that used the errant code. The bug no longer existed, but neither did the functionality that was supposed to be there.) A bug needs to be documented, the fix should be thought through, and the implications considered. Then the code should be changed, comments added, and the code should be checked into source control. Once the code has been fixed, it should be unit tested, and only then should the entire system be tested. Yes, this is bureaucratic, time consuming, and it forces developers to write reports when they should be writing code. But in the long run, it provides better code-and better quality code.

EnC does not encourage such a careful practice of fixing code. It encourages quick fixes on the fly-fixes that get the code working at that point in time. A developer could make many such changes to code in one session and all of these changes will be checked-in at a single time. This implies that the changes are associated with each other, which is not necessarily the case. Would the developer be able to remember all of the reasons that were considered when deciding how to change the code?

It seems to me that the overwhelming reason for adding EnC to .NET is because VB always had it. Is that a legitimate reason? VB developers tell me how much time it saves them, but I argue that in the long run, it does not save them time because, as I have already mentioned, fixing a bug involves more than just changing some code.

Finally, I come to my main complaint about EnC. In spite of its size, Microsoft has finite resources, and as a veteran beta tester of .NET, I frequently found that bugs I reported would be marked as "scheduled to be fixed in a later version. I understand that Microsoft does not have the workforce to fix every bug as soon as it is identified; however, as I have already mentioned, adding EnC required changes to the runtime, and this took a significant amount of effort. But it means that some other (possibly more important) feature has had to be shelved. EnC will only be available to VB.NET developers (although a future version of .NET could provide it for C#, too), so you have to question that if the feature is only available to one language, then it surely cannot be a feature essential to .NET. I would have preferred the effort to be expended in features that would have benefited all .NET developers.

Returning to my question: Do we really need Edit and Continue? My answer is no.

Richard Grimes speaks at conferences and writes extensively on .NET, COM, and COM+. He is the author of Developing Applications with Visual Studio .NET (Addison-Wesley, 2002). If you have comments about this topic, Richard can be reached at richard@richardgrimes.com.

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.