Frans Bouma's blog

# Hear hear!@ Thursday, July 31, 2003 8:40 AM

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:)

Mads Nissen

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 9:07 AM

Completely disagree. If I'm testing my application and an exception fires because, say I'd used the wrong type of slash in XPath, then I want to fix it, then carry on. This results in a quick, trivial change, rather than the 30-40 seconds required to stop the debugger, let VS.Net rearrange all it's docked windows, make the change, fire up the debugger. Navigate through the application to the same spot the exception fired so that I can carry on testing from where I left off.

I would agree that pure logic should not be built on the fly - it should take a more formal approach, but stupid coding mistakes need to be squashed rapidly while testing your code.

Unit Testing (as in xUnit) doesn't help in most of these situations if the coding error was part of the presentation layer.

I've written parsers, web apps, win apps in C# all with NUnit during the last 3 years and regularly wish I had E&C.

RichB

# Why Edit and continue is a GOOD thing@ Thursday, July 31, 2003 9:25 AM

TrackBack

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 5:23 PM

Hehe VB crap... debug, change your program, serious hang, terminate the app and IDE shuts down as well.

BOOM, al changes are lost... what the hell did I just do?

Welcome in the world of crappy programming pratices. Please MS leave Edit & Continue out of C#. Disfunctional coding pratices should have their own disfunctional language (VB), let it not be C#.

My 2c

Paul Gielens

# re: Why Edit & Continue is a bad thing@ Thursday, July 31, 2003 6:20 PM

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

HumanCompiler

# Frans Bouma's says Edit and Continue is a bad thing@ Thursday, July 31, 2003 9:21 PM

TrackBack

# More on the badness of E@ Friday, August 01, 2003 7:29 AM

TrackBack

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 2:09 PM

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.

Charlie Zimmerman

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 3:40 PM

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 Meston

# re: Why Edit & Continue is a bad thing@ Friday, August 01, 2003 3:42 PM

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

Frans Bouma

# This seems an overreaction@ Monday, August 04, 2003 10:38 PM

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.

Ben Langhinrichs

# re: Why Edit & Continue is a bad thing@ Tuesday, August 05, 2003 10:24 AM

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.

Keith Keller

# re: Why Edit & Continue is a bad thing@ Sunday, October 05, 2003 1:12 PM

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.

Dr_Barnowl

# re: Why Edit & Continue is a bad thing@ Sunday, December 21, 2003 1:43 PM

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

george

# re: Why Edit & Continue is a bad thing@ Tuesday, February 10, 2004 4:14 PM

Hey George, you missed one little thing: Edit & Continue IS ALSO PRESENT IN VISUAL C++. While you are debugging, you can modify code, then press ALT+F10 to compile in a flash, then you continue debugging.

In my opinion, E&C is just an extension of the facilities of the debugger. If you shouldn't modify the code while you are debugging, you also shouldn't change the current executing statement, or the values of variables, to mention just a couple of cases that you CAN do with C#. If we take this reasoning to its extreme, then we should not debug at all: if the program crashes, we should just sit down and scratch our brains to figure out where the error is without incurring in the heresy of running it step by step... shouldn't we?

It's a matter of programmer judgement up to what point the E&C feature is used. It is great for those cases where you mistyped a ">" for a "<". That is a stupid error that do not merit that you stop the program, mostly if it has taken you a long time to get there.

Mostly, if VB.NET is going to have E&C and C# is not, this will certainly give the VB fans and argument against C# which is IMHO a superior language.

In a nutshell: E&C won't make a bad programmer out of a good one, but will save lots of time to everybody. Let each one decide instead of forcing everybody not to use it.

Marco

Marco A. Perez

# re: Why Edit & Continue is a bad thing@ Tuesday, February 10, 2004 4:19 PM

You completely missed my argument what debugging is all about. You can jump up and down all day long that E&C is a great thing, but in the end it will blind you for teh real issues about debugging. People who think for 20 seconds, then start debugging can outperform any 'E&C' using person in any occasion.

The only argument I see recurring is that it helps you fix silly typo's. oh, well, I can fix them when I stop the debugger as well and then I know they're corrected. If you do not know if they bug is then fixed, you are using trial and error, and proving my points.

Frans Bouma

# re: Why Edit & Continue is a bad thing@ Thursday, March 18, 2004 1:29 PM

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?

Stephen Johnston

# re: Why Edit & Continue is a bad thing@ Wednesday, March 24, 2004 7:08 AM

I'm afraid I would side with RichB on this one, the issue here is not so much to do with E&C as with the time it takes for VS.Net to pick itself up off the floor when you stop the debugger. This is why E&C is useful, but only for the typos, I agree - but these are precisely the 'easy' bugs that you want to waste the least possible time on, so that you can get on to the 'real' bugs.

Benjol

# re: Why Edit & Continue is a bad thing@ Tuesday, May 11, 2004 4:38 PM

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.

Ron Barone

# re: Why Edit & Continue is a bad thing@ Friday, June 18, 2004 7:00 PM

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!

Eric Schleicher

# re: Why Edit & Continue is a bad thing@ Saturday, June 19, 2004 4:05 AM

"E&C is an invaluable part of programming. "
Proof it. This is just a claim.

"Both as an educational tool, and for debugging in the sense you refer to it. "
Educational tool perhaps but if you want a good educational tool, you need a tool especially made for education. For debugging as I refer to it, I don't see it as an invaluable tool as I state that the cases in where you CAN USE E&C are pretty slim.

"E&C was on of the major contributing factors in VB/C++ success, as it enabled non-experts such as yourself, rapidly develop applications."
Proof it, again a claim.
C++ success was not based on E&C, ever used it in C++? In a regular application with a few thousand lines and a couple of subprojects?

Oh and I'm not a non-expert, Eric.

"It sounds like you're a pretty hard core .NET'er"
Well, after my CS graduation I have now done 10 years of professional software development.

"so surely you're a stanger how rapid development work in the real world. "
Perhaps you should open your eyes and read about what I do for 'rapid development work' before again, claiming something.

"I've found .NET's (CLR) inabilty to E&C the major limiting factor in enterprise usage uptake... "
Based on what? Java is the no.1 platform in enterprise computing. AFAIK it doesn't have E&C, never had, never will.

"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. "
Oh really? Perhaps I try to tell people how they REALLY should debug their software so they are more productive and know more knowledge. I already know a lot of that through years of experience. Others don't. That you see it as an elitist perspective is your problem, not mine. Btw, you think I'm a non-expert, a retart, a stranger to how it goes in the real world... and *I* am the elitist here? :D.

"As Ron (Above) noted, if the code is that same in the end, and it takes less time, then it's better."
IF it takes less time, then yes. No-one has proved it will take less time with E&C.

Frans Bouma

# re: Why Edit & Continue is a bad thing@ Thursday, July 01, 2004 3:20 AM

it's always a laugh reading this entry and the various comments. I've bookmarked it so i can come back every few months.

cheers :+)

secretGeek

# Edit @ Friday, October 15, 2004 5:49 PM

TrackBack