Monday 4 August 2003 — This is more than 21 years old. Be careful.
Frans Bouma rants about Edit and Continue. He claims it encourages bad debugging style. I wouldn’t go that far, but I don’t use Edit and Continue because I don’t believe in it. Not “don’t believe” as in “I think it is poor practice”, but as in “I think it is impossible”.
Now of course I know the feature is implemented, and many people use it, and they are happy with it, so it must work for them. But it doesn’t fit my mental model of how software systems can operate. When I have tried it, it either works, which seems miraculous, or it doesn’t, which is disappointing. So I don’t believe in it, and don’t use it.
For those that may not know: Edit and Continue is a feature of Microsoft development environments where a running program can be edited, recompiled, dynamically patched, and execution continues.
Comments
Have you ever tried edit and continue while in a debugging session from a remote machine using VC++? Now that is something that should be impossible!
As for the rant, I think he was posturing more against the use of debuggers in general, rather than explictly against edit-and-continue. I wish he had just talked about good debugging techniques rather getting caught up with edit and continue (which in my opinion is a feature the visual studio team put it in there just for the coolness factor). I whole-heartedly agree with his point, though - I think we often dive into using the debugger too soon into the debugging process. As a result, the deubgger becomes a crutch rather than a tool. For the longest time, I resisted using a debugger - most of my coding was done in Java in windows/UNIX and I would debug using a combination of pre and post condition checks, strategly placed system.out.printlns, and Java's inbuilt stack traces. Admittedly, the scope of these projects was small (usually <= 5 people on a team and < 10,000 lines of code). Still, even on larger projects where there are more unknowns, resisting the tempation to use a debugger has its benifits. Firstly, it forces the programmer to have a larger picture of the code that he is trying to debug rather than focussing on a tiny section of the code around a breakpoint. When you don't use a debugger, you automatically manually review the code, and naturally perform steps 1-3 in Frans' article, before actually running the code to debug the problem. Secondly, it forces you follow the execution path from beginning to end, rather than just wait for the code to hit the breakpoint. This can lead to "better" bug fixes because you end up viewing the bug from the top down, thus resisting the tempation to just patch the bug at it lowest level. But most importantly in my opinion, not using a debugger forces you to write code that is easy to debug! You are much more inclined to check pre and post conditions as well as include informational log messages if you know that those are going to be your means of debugging.
--Nosh
Add a comment: