Why Edit & Continue is a bad thing

12 Comments

• Very much agreed. The (language)discussion is going loud around here these days. This is a point I'll definately use in the office wars:)
  

• Blame the languages for good and bad all you want, but it still all depends on the person behind the keyboard! ;)
  

• If you think it's bad, don't use it. But put it in there for the people who like it. I want freedom, not constraints imposed on me from the Best Practices Police.
  

• I am kind of amazed at the negative reaction that people are showing for EnC. I don't understand it. How does fixing a stupid bug while debugging and without recompiling encourage bad programming practice? That kind of thing happens to everyone no matter how much forethought you put into your design.
  

• Tosh: read my other article about debugging I posted today. You'll understand why.
  

• It is easy to dismiss the plain stupidity bugs, but when working on a mature product, a large amount of time spent debugging is spent on such bugs. If you add a new method and it gets halfway through a million steps of exiting code (some sort of an engine), it is a heck of a lot easier to fix and continue than to stop and get back to where you were. Granted, that is also a reflection of the tools available, but what if several human interaction steps are required to get to that point. Recreating them over and over to reproduce the situation rather than using Edit&Continue seems extreme.
  
  
  
  Having said this, note that I don't have or use E&C in the compiler I have now, but I think the concept is well founded. The implementation is another question, and I do think it is a fair argument to say that there may be better walls for the developers to throw themselves at.
  

• I've developed with tools that don't have E&C and I can tell you this, having it saved me more time than not having it. Particularly when it takes me 1/2 the time to locate and fix the problem using E&C as opposed to having to categorize and determine the cause of the bug. An application that I work on now is what's called an Allocation Engine. It's sole purpose is to perform extensive calcs against a database to provide Oil & Gas companies with the info they need to determine what was produced and what was sold. It has no user interface and hundreds of functions and objects. It is written in Powerbuilder. When a customer reports a bug to us, it can literally take an entire workday (sometimes more) to figure out where the bug is and what is causing it. In order to assist us in this, we generate trace files and insert message boxes. Powerbuilder has NO Edit and Continue. Under the same scenario, using VB6, it would have taken us roughly 1/2 the time to locate and fix the bug because some of these bugs don't pop up until after thousands of lines of code have executed and several minutes or an hour has gone by. By inserting a breakpoint (which PB does have) near the area where we believe the bug originates. We then begin stepping through the code and "watching" the values. Once we see what's happening, (using E&C) we can easily change that line, step into it, check the result and then continue on with the allocation.
  
  
  
  The real beauty here is that "IF" you don't like E&C, then don't use it.
  

• As a VB6 programmer by trade, I prefer C# as a language ; Whenever I try VB.NET, I start to unconsciously use VB6 syntax. And since I'm still working on active bodies of VB6 code all the time, I don't really need VB.NET syntax cluttering up my head and taking over.
  
  
  
  But I really miss Edit & Continue when I write C# code ; particularly because I'm still learning C# and the .NET class libraries. While a lot of things will be caught by the compilers, and I agree that test-driven development is the way forward, E&C really helps you learn.
  
  
  
  I came to software development with zero professional experience from the medical profession : I was pretty much thrown staight in at the deep end and had to learn VB6 in a matter of weeks (on the redoubtable foundation of BBC and Spectrum BASICs). E&C was a great help ; when you've put a couple of parameters round the wrong way because of inexperience, it's a great boon to be able to shift the run pointer back a line and swap them round.
  
  
  
  The other thing I miss with .NET is the ability to execute code in the immediate window without being in break mode ; the VB6 immediate window has many uses, from looking up character codes without having to trudge through the help, performing large calculations that you don't trust the default calculator with, etc.
  
  
  
  Convenience features don't make you less of a "man". And you don't always have the luxury of well-structured code with decent testing frameworks ; very often, you're working with code that others wrote, and of questionable quality. My time maintaining our huge, ancient VB3 app has made me very, very glad of E&C.
  

• Edit and continue save so much time when fixing trivial errors that it is a shame it hasn't been implemented yet - whenever I read the ENC comments form C# people, it's just typical of their "my way of the highway" mentality that keeps progress in the 19th century. Get over it C# people, there are some nice features in VB that put the IDE ahead of the C world you are accustomed to and it's time you opened your mind and stop acting like bunch of geeks. Just because you are C people doesn't really make you better programmers - it just proves you like to suffer more than the rest of us.
  
  
  
  George
  

• Currently I write test harnesses for a lot of my code. I wouldn't mind using edit and continue to unit test the code, before even writing the test harness to allow a tester to test it more thoroughly. In this way, I can focus on the two task seperately. Less confusion, better code, etc.
  
  
  
  If you guys are all writing such well planned out code, that you never use any "trial and error" methods.... do you even test your code?
  

• Here's the deal. Back in the early part of the 1960, 70's and 80's processing power was scheduled for things like compiling etc. This is where edit and continue woudlnt work, and wouldnt be nearly as efficient. The code SHOULD be thought out before even attempting a compile, becuase when there was an error a day was spent and time was wasted on a 'stupid' typo.
  
  
  
  I have been coding for quite some time, and consider myself a good engineer. There are times when E&C shouldnt be used, but you put me up against another coder with the same exp. not using E&C I will develop it faster.
  
  
  
  Everyone has to remember that opinions about not using E&C ARE OPINIONS. They dont apply to everyone, but they do apply to you.
  
  
  
  In the end if the code is the same, and it took less time using E&C (which it will if used correctly), E&C should be used. That's not an opinion that's a fact.
  
  

• As a long time business application developer (read not academic programmer) E&C is an invaluable part of programming. Both as an educational tool, and for debugging in the sense you refer to it. E&C was on of the major contributing factors in VB/C++ success, as it enabled non-experts such as yourself, rapidly develop applications. It sounds like you're a pretty hard core .NET'er... so surely you're a stanger how rapid development work in the real world. I've found .NET's (CLR) inabilty to E&C the major limiting factor in enterprise usage uptake...
  
  
  
  to think that it's only use is to enable lesser programmers to debug by trial and error is a purely elitest perspective. and for stating, you've made an ass out of yourself.
  
  
  
  As Ron (Above) noted, if the code is that same in the end, and it takes less time, then it's better.
  
  
  
  what a 'tard!