Edit and Continue

[Jeremy]

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in using
it. Am I missing something?

Thanks!

 

[Jonathan Wood]

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just edit
and continue. Which would you prefer?

 

[Jeremy]

My prior experience with Edit and Continue (vb6, vba, etc) is that it's a
feature that, IF it were to function as advertised, might prove useful. But
things would periodically go wrong - thereby wasting much more time than the
feature was intended to save. Furthermore, assuming that it now "works as
advertised" it seems that changing a line of code while the application is
running might cause unknown (even unpredictable) conseqeunces.

You can see that I'm reluctant to try it again based on the considerations
given above. But rather than simply dismissing it, I'm wondering if there is
some aspect of [Edit and Continue] that you more experienced developers
conclude makes it a must-have feature. Do any of you use it "all the time"
or as a matter of course? Or do most of you prefer to not use it?

Thanks.

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just
edit and continue. Which would you prefer?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in
using it. Am I missing something?

Thanks!

 

[Michael C]

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in using
it. Am I missing something?

It's just a time saving feature in my opinion, if you notice a mistake in
your code then you can change it without having to restart your app. This is
especially useful if it took a long time to get to the point your code is
at, eg at the end of a long import.

You're going to get replies from people who never need this feature because
they never make mistakes and always check their code before running it and
it works perfectly first time every time. But for those not living in
newsgroup fantasy land it is a very useful feature (not that I've got vs2005
but I'm using visual basic 6 on 1 project).

 

[Michael C]

My prior experience with Edit and Continue (vb6, vba, etc) is that it's a
feature that, IF it were to function as advertised, might prove useful.
But things would periodically go wrong - thereby wasting much more time
than the feature was intended to save.

The feature works pretty much perfectly in vb6, I don't know where you're
getting the idea that it doesn't work as advertised. It does require some
understanding of what is going on.

Furthermore, assuming that it now "works as advertised" it seems that
changing a line of code while the application is running might cause
unknown (even unpredictable) conseqeunces.

The usual situation is that you get an error, fix a simple mistake and
continue, but getting the error might cause some side effects. You just need
to take this into account but it's rarely a problem.

Michael

 

[Jonathan Wood]

I very rarely use it. But on those rare occasions, it can be nice. But,
frankly, I just don't see any downside to it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

My prior experience with Edit and Continue (vb6, vba, etc) is that it's a
feature that, IF it were to function as advertised, might prove useful.
But things would periodically go wrong - thereby wasting much more time
than the feature was intended to save. Furthermore, assuming that it now
"works as advertised" it seems that changing a line of code while the
application is running might cause unknown (even unpredictable)
conseqeunces.

You can see that I'm reluctant to try it again based on the considerations
given above. But rather than simply dismissing it, I'm wondering if there
is some aspect of [Edit and Continue] that you more experienced developers
conclude makes it a must-have feature. Do any of you use it "all the time"
or as a matter of course? Or do most of you prefer to not use it?

Thanks.

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just
edit and continue. Which would you prefer?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Is [Edit and Continue] a worthwhile feature?

I've lived just fine without it for years... don't see much value in
using it. Am I missing something?

Thanks!

 

[Greg Miller]

But things would periodically go wrong - thereby wasting much more time than
the feature was intended to save. Furthermore, assuming that it now "works as
advertised" it seems that changing a line of code while the application is
running might cause unknown (even unpredictable) conseqeunces.

I'm curious as to what types of problems you ran into.

 

[Jon Skeet [C# MVP]]

Why not?

While debugging your code, you might see a line you want to change before
executing it. You can make the change and restart the program, or just edit
and continue. Which would you prefer?

Restart the program - otherwise I can't be sure that my change won't
have affected anything I've already done.

Of course, with a good battery of unit tests, "restart the program"
actually means "rerun the test" which I'd be doing anyway.

 

[Jon Skeet [C# MVP]]

I very rarely use it. But on those rare occasions, it can be nice. But,
frankly, I just don't see any downside to it.

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Now, this could be a myth, and it can certainly be avoided just by
being disciplined about when you use it. I *can* see E&C being useful
when trying different ways of presenting a UI - but I wouldn't want to
use it for fixing bugs.

 

[Steven Nagy]

I agree. I think there is a possibility that it can breed complacency.
I think it can be used in moderation, but as Jon said, only for small
UI or similar situations. You don't want to rely on E&C. Its good that
its been absent for a few years, and I personally don't use it at all.

Jon, got any really good resources on unit testing in .NET ?
They're going to push Nunit on us at work and I want to be completely
prepared.
I have never before developed from a test-driven approach. I understand
the basic concepts of writing testable methods, but only the basics
mind you.
I'm sure there are lots of resources available that a Google would
find, but I want to know what YOU recommend.

Cheers,
Steven

 

[Jon Skeet [C# MVP]]

You're going to get replies from people who never need this feature because
they never make mistakes and always check their code before running it and
it works perfectly first time every time. But for those not living in
newsgroup fantasy land it is a very useful feature (not that I've got vs2005
but I'm using visual basic 6 on 1 project).

I've never seen anyone argue against E&C on those grounds. I *have*
seen people argue against E&C on the grounds that fixing a problem
while the program is running only shows that it's been fixed at that
particular point in time - the fix could easily have prevented you from
getting to the situation in the first place. Where possible (and with
some advanced techniques and appropriate design it's *almost* always
possible) unit tests can get you *repeatable* testing so that when a
bug is found, you can make sure it's fixed, stays fixed, and that the
fix doesn't adversely affect anything else. It's not a silver bullet,
but it's better (IMO) than using E&C and doing all testing manually.

 

[Michael C]

I've never seen anyone argue against E&C on those grounds.

I've seen plenty

I *have*
seen people argue against E&C on the grounds that fixing a problem
while the program is running only shows that it's been fixed at that
particular point in time - the fix could easily have prevented you from
getting to the situation in the first place. Where possible (and with
some advanced techniques and appropriate design it's *almost* always
possible) unit tests can get you *repeatable* testing so that when a
bug is found, you can make sure it's fixed, stays fixed, and that the
fix doesn't adversely affect anything else. It's not a silver bullet,
but it's better (IMO) than using E&C and doing all testing manually.

What you're really saying is that because EC can be misused it should never
be used. Before you get to the point of unit testing you're going to have to
at least do some basic testing and EC can be very useful in those situation.

Michael

 

[Shawn Wildermuth (C# MVP)]

Hello Michael,

I have E&C turned on but it never seems to work. Does anyone know if this
is a limitation of ASP.NET (where I have tried to use it)?


Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com

 

[Jon Skeet [C# MVP]]

I've seen plenty

Care to give any examples? I've been in this discussion plenty of
times, and never seen anyone claim they never write any bad code.

What you're really saying is that because EC can be misused it should never
be used.

I'm saying that because E&C *is* misused, it's a dangerous feature to
have around.

Before you get to the point of unit testing you're going to have to
at least do some basic testing and EC can be very useful in those situation.

Um, no. I write my unit tests before I write my production code. Even
if I didn't do TDD, why would I do "basic" testing manually when I can
automate it and get the benefits again and again?

Jon

 

[Chris Nahr]

Given your signature you're probably talking about C# code? In that
case, I can assure you that E&C has never worked for me, either -- and
I'm using C# without ASP.NET...

 

[Michael C]

Care to give any examples? I've been in this discussion plenty of
times, and never seen anyone claim they never write any bad code.

This was when dot net came out how ever many years ago. Many claimed they
didn't use EC because they checked all their code before running it hence
had no bugs. A search of google should find something.

I'm saying that because E&C *is* misused, it's a dangerous feature to
have around.

Exactly, which is a pretty silly reason not to have a feature.

Um, no. I write my unit tests before I write my production code. Even
if I didn't do TDD, why would I do "basic" testing manually when I can
automate it and get the benefits again and again?

This is the sort of thing I call "newsgroup fantasy land", it's amazing to
watch as everyone all of a sudden starts doing everything perfectly to
support some particular arguement. I'd say 90% of developers or more would
never have done a unit test and 99% wouldn't use them for all their code.
The only time I do unit testing is for some critical components. If I was
writing device drivers then I would but I don't do that sort of work.

Michael

 

[Jon Skeet [C# MVP]]

Exactly, which is a pretty silly reason not to have a feature.

Well, I've found it a pretty compelling reason for C# not having
macros, templates (gaining the more limited but useful generics
instead), overloading of assignment operators, etc.

This is the sort of thing I call "newsgroup fantasy land", it's amazing to
watch as everyone all of a sudden starts doing everything perfectly to
support some particular arguement.

Are you claiming I *don't* practise TDD? Note that I'm not claiming I'm
perfect - quite the reverse. I write unit tests because I'm *not*
perfect - because I *do* have bugs in my code, and without unit tests
I'll miss a large proportion of them. (With unit tests, I'll still miss
a few - but much fewer.)

I'd say 90% of developers or more would
never have done a unit test and 99% wouldn't use them for all their code.

Then they should address that rather than using the crutch of E&C.
Using E&C addresses the symptom rather than the cause.

The only time I do unit testing is for some critical components. If I was
writing device drivers then I would but I don't do that sort of work.

Well, I've found it's improved the quality of both my design and
implementation, and saved me time in the long run. Why wouldn't I want
to do that on all code I plan to keep around for significant amounts of
time? (I don't personally unit test prototype code thoroughly, although
some unit tests are still worthwhile even then.)

Jon

 

[Michael C]

Well, I've found it a pretty compelling reason for C# not having
macros, templates (gaining the more limited but useful generics
instead), overloading of assignment operators, etc.

I have to agree there, especially with macros. I'd also add VB6's With
operator to that Although those features are stuck in code for ever.
You've got no way to tell if someone used EC by looking at their code.

Are you claiming I *don't* practise TDD? Note that I'm not claiming I'm
perfect - quite the reverse. I write unit tests because I'm *not*
perfect - because I *do* have bugs in my code, and without unit tests
I'll miss a large proportion of them. (With unit tests, I'll still miss
a few - but much fewer.)

I think you're exaggerating.

Then they should address that rather than using the crutch of E&C.
Using E&C addresses the symptom rather than the cause.

No it doesn't. It's just a convenience. Even if you write unit tests for
everything there has to be a point where you first run said code. At that
point you might notice you've written "DELECT * FROM" (as I often do) and
can easily fix it without a restart. I don't see how that is bad practice or
likely to cause problems. Even on the occasions I've written unit tests i've
still run the code manually beforehand, eg when writing a stored proc I'll
test it in query analyser first.

Well, I've found it's improved the quality of both my design and
implementation, and saved me time in the long run. Why wouldn't I want
to do that on all code I plan to keep around for significant amounts of
time? (I don't personally unit test prototype code thoroughly, although
some unit tests are still worthwhile even then.)

I just don't see how unit tests can apply to all of my code. How am I going
to test drag/drop with a unit test? In a lot of testing I think it needs a
person there to do it, especially business style database apps.

Michael

 

[Jon Skeet [C# MVP]]

I have to agree there, especially with macros. I'd also add VB6's With
operator to that Although those features are stuck in code for ever.
You've got no way to tell if someone used EC by looking at their code.

Unless you see that changes haven't been planned so much as done on the
spur of the moment, to address a single point in time rather than a
more general issue. I'm not saying you'll always be able to point to
it, but if E&C is abused, I believe it will be at least somewhat
evident.

I think you're exaggerating.

You've never met me. You've never watched me code. Which part do you
think I'm exaggerating, and what evidence can you possibly have for
that belief?

No it doesn't. It's just a convenience. Even if you write unit tests for
everything there has to be a point where you first run said code. At that
point you might notice you've written "DELECT * FROM" (as I often do) and
can easily fix it without a restart. I don't see how that is bad practice or
likely to cause problems. Even on the occasions I've written unit tests i've
still run the code manually beforehand, eg when writing a stored proc I'll
test it in query analyser first.

The benefits of E&C are almost always stated in terms of not taking a
long time to get back to where you were. With unit tests, that time
just isn't there. It's very quick to just change the code and rerun the
unit tests. Given that you'd need to rerun the unit tests anyway to
give you overall confidence of the change, where's the benefit of using
E&C?

I just don't see how unit tests can apply to all of my code. How am I going
to test drag/drop with a unit test? In a lot of testing I think it needs a
person there to do it, especially business style database apps.

What part of database applications can't be unit tested? UI work is
indeed a lot harder to unit test, but that's only one (hopefully
well-separated) layer - and where logic is required in the presentation
layer, that can still be tested. As I think I said before, UI work
could possibly benefit from E&C, but if there is logic to be changed,
I'd still unit test that and make changes by rerunning the unit tests
rather than E&C.

Jon

 

[Jonathan Wood]

Jon,

The potential downside I see is that it encourages "development by
tinkering" - fix this particular problem, but don't bother checking
that nothing else is broken. I believe there are developers who write
more code in the debugger than not.

Now, this could be a myth, and it can certainly be avoided just by
being disciplined about when you use it. I *can* see E&C being useful
when trying different ways of presenting a UI - but I wouldn't want to
use it for fixing bugs.

This assumes facts not in evidence.

I've been programming 20 years now and feel I know adaquately how to write
and test programs. Yet, I've just indicated I may on occasion use edit and
continue.

Should we eliminate pointers because someone without experience might abuse
them? I hardly see that some folks might abuse a feature as a downside to
having that feature.