On Edit and Continue


Dennis Forbes talks about "Edit and Continue" in VS 2005 and asks "Is it, coupled with similar tool advances, making programmers sloppier, though?"

I think so...

In the Visual C++ debugger we've had "Edit and Continue" for years but I turned it off a long time ago as I didn't find it that helpful. It enables and encourages quick hacky experimental fixes to running code. I never really liked that idea, I usually prefer to think about the problem rather than just hacking in a fix, and back in the early days of VC6 the whole incremental link/edit and continue thing sometimes introduced interesting bugs that seemed to go away if you did a full clean build. I'm sure the Edit and Continue support is much better these days but I find that using unit tests usually means that I spend less time in a debugger; which is handy since some of the development enviornments that my clients use don't have a debugger installed (go figure)... If you get adicted to living in the debugger and thinking of code as something so fluid that you can change it at any point, even during execution, then it's hard to break the habit and be productive if you have to drop back to the bad old days of printf debugging or worse...

Of course I'm sure there are plenty of people who couldn't live without Edit and Continue, I'm just not one of them.


Having been a long-time user of E&C in the VB.Classic IDE, I have mixed feelings.

There are both benefits and dangers to this feature, and on balance, I feel that the benefits outweigh the drawbacks. The arguments against E&C tend to emphasise the dangers of this feature in the hands of inexperienced developers. Well, almost everything is dangerous in the hands of an inexperienced developer. so that's just not a convincing argument for me. And if you do understand what you're doing, E&C can be a great benefit.

Enough preaching. Like any subject, the devil is in the details. So let's look closer at some typical uses of E&C.


Your article on this (http://sleeksoft.co.uk/public/techblog/articles/20051224_1.html) makes some good points. I think, perhaps, that my continued avoidance of E&C is down to not really needing it when you have fine grained unit tests. The advantage, as I see it, of E&C is that it might take you a while to get the code into the situation that you're debugging, once there, being able to change the code without having to restart is a boon. With decent unit tests you can avoid the time required to get the code back into the correct state, you have a test that puts it there straight away so it doesn't actually matter quite as much if you stop, change and rebuild the code. Then again, thinking about it, perhaps there isn't such a difference between my quick to apply changes done due to focussed testing and small amounts of execution and the E&C way with large amounts of execution (running the whole program)... If I didn't have the tests perhaps I'd like the E&C.

I do agree that the more code coverage given by your unit tests, and the more functions covered by your scenario tests, the less often you'll need to use E&C.

But I still find it a useful extra tool in my arsenal. I don't just rely on my unit tests - I also step through ALL of my new code in a debugger. And E&C is a significant aid to me in this latter situation.

I must admit that I have been known to tweak variables in the debugger, mainly by simply re-evaluating them with the required value (and I get a little upset when const means const (and unchangable) even in the debugger!) so I suppose that and the small scale execution that I get from my tests means that I am effectively doing E&C even though I don't think I am...

As with any tool E&C is appropriate for some tasks and less so for others. It is a clearer win for prototyping, and quick development scenarios. (e.g. places where VB6 ... and hopefully VB8 in VS 2005 really shine.) To that extent it is unsurprising that it is not the most popular feature in C++.

Every C++ dev I've met who used E&C, did so for Windows GUI development. Simply being able to quickly experiment was a huge benefit for them.

E&C can be used in large scale development projects, but just like every tool in such projects it needs to fit in carefully with many others. Build labs, deployment policies, etc can make it less feasible to use, and very careful development methods can make it's productivity boost less impressive.

Finally the type, size and number of applications you write makes a big difference on whether E&C is a critical feature for you. E&C is a clear win for prototypes. Interaction design with an E&C enabled tool is also a clear win. If you are 1 dev servicing 100 tiny applications rather than 1 of a 100 devs on 1 large application then E&C is probably for you.

The issues around unit testing, and careful coding are less meaningful if the primary success criteria for your application is quick completion.


Yeah, I see your point. I think I've changed my mind on this one. I can see how the way I work is, to be honest, quite similar to the kind of effects you can get with E&C so I guess I do do it and I do find it effective I just don't use the tool support that often at present. I expect that may change a bit as I migrate from VC6 to VC8... We'll see.

Leave a comment