Edit and Continue Leads to Bad Programming Habits?

One of the things MS is returning to VB with the Whidbey release is Edit and Continue Debugging feature. I for one do not see why this is such a great thing, and I was a VB 3-6 programmer. I never used this feature, and don’t encourage its use. I talked to a couple developers last night about this, and they were all in favor of it. They were trying to say that it saves them time coding and debugging, but if it takes you that long to build and step thru code to get to the area of code you are trying to debug, maybe the problem is your architecture, not the debugging tools. I break my apps into logical and physical components, and create test harnesses for each component. This way I get true unit testing, and only have to concentrate on debugging one component at a time. Once I get the component working correctly, I rarely have to step thru it while debugging another component. It makes my life so much easier, and eliminates the crazy spaghetti code that can occur if you try to put everything in one project. If I have to go too deep into a component, I trying to see if I really need it all in one component. Sometimes I do, but more than likely, I didn’t, I was just lazy, and didn’t split it out. Without Edit and Continue, it forces me to evaluate if I really need that code in the same project. Just my opinion.

DonXML
[Listening to: I Don't Care (So There) - The Donnas ]

10 Comments

  • Greg, I understand what you are saying, but I specificially made this post to get people thinking about why they are using Edit and Continue. There are places were it is useful, but you should question why are you coding and debugging this way, and is there a better, faster (in the long run) way.



    Sometimes it is good to step back, and re-evaluate why you are doing things a certain way. If I get at least one person to remember to do that, than the post was worth the possible flame war.

  • Don, I couldn't agree more. While edit and continue is a nice to have it certainly isn't close to some of the other features which C# WILL have such as generics!

  • Thanks Don...

    "Sometimes it is good to step back, and re-evaluate why you are doing things a certain way.."



    I totally agree with you there.



    Sometimes you just HAVE to get out of the boat. <- one of my favorite scenes from Apocalypse Now... "Never get out of the boat...">

  • I made the same post on one of the microsoft.public newsgroups, and got about the same reaction. I don't see the need for E&C, I think it yields to lack of forward design skills. I can honestly say that I did use it, but only very occasionally where I was under some insane deadline and code quality didn't really matter.



    One of the problems solved with E&C in VB6 and prior was the lack of a true compiler, or at least an IDE that took advantages of its underlying compiler.



    But you can't ignore the fact that so many seem to want this feature. Go ahead, throw it in. I won't use it, but if it quiets the masses that complain about it as a large stumbling block, then it is my new favorite feature.

  • I guess I just don't understand all the fuss. When I did a lot of VB6 stuff, I never really used Edit and Continue. In fact, on the biggest project I've ever touched, I didn't even have the option (for reasons too lengthy to address here). It might sound crazy, but debugging was almost not even possible (had to do with paranoid admins, DBAs, etc. - it was tough).



    Anyway, I've been perfectly happy with C#'s "Edit and Stop" system.



    Regardless of Edit and Continue preference, this bit of the post was golden: "[I]f it takes you that long to build and step thru code to get to the area of code you are trying to debug, maybe the problem is your architecture..."

  • I agree 100% with you Don... Edit & Continue is a *nice* feature, but does it really lead to better code? I doubt it. If you're editting code while your application is running, you may actually end up breaking some other logic somewhere before that newly editted code actually executed (ie: not break it per se, but null out effect of code running before it). In most cases I believe that if you're using Edit & Continue you'll end up going back and debugging that same section of code again. So, I ask, is it really worth it?

  • Amen, brotha man. I've just recently been turned on to some of the Extreme Programming principles and the whole test-driven development concept is really resonating with me. When you apply "hardcore unit testing" with "small, isolated changes between builds", it's easy to see why the use of a debugger would be rare (especially when you throw in pair programming).

  • Don, I agree with you 100%.

  • E&C is one of the things I hated most about VB6. I can remember several instances where I questioned a junior developer about why they wrote a certain portion of code a particular way, and the response was "that made it work".



    That said, when I first returned to programming without the ability to E&C I did in fact miss it. It's worth the inconvenience though.

  • These anti Edit and Continue dummies remind me of old mainframe coders that used to tell me that dependence on a debugger leads to weak programming habits. They used to tell me that if they really need to debug a section of code (in the rare case that it did not work the first time) they would add a few debug writes.



    Now the children of these idiots are using similar arguments against a great productivity boosting feature-edit and continue.



    E and C allows you to incrementally verify as you go rather than compound your mistake due to postponed verification. The dummies would have you stop and restart your program, and reproduce the steps to get you to the same place in your code every time you encounter and issue.



    Guess what-



    The guys that use these tools effectively write code that works much more often (and faster) than the dummies that code with one hand tied behind their back.



Comments have been disabled for this content.