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!

[Jon Skeet [C# MVP]]

Michael C <no****@nospam. comwrote:

<snip>

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

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]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

>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

[Jon Skeet [C# MVP]]

Michael C wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

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

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.

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.

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...

On Wed, 19 Jul 2006 07:28:55 +0000 (UTC), Shawn Wildermuth (C# MVP)
<sw*********@ne wsgroup.nospamw rote:

>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

--
http://www.kynosarges.de

[Michael C]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ s13g2000cwa.goo glegroups.com.. .

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]]

Michael C wrote:

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.

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.

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.

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]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ 75g2000cwc.goog legroups.com...

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]]

Michael C wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ 75g2000cwc.goog legroups.com...

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.

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.

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.

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?

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.

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?

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.

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,

>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 "developmen t 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.

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