Edit and Continue

[Jonathan Wood]

Jon,

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

Your assumptions aside that saving time using Edit and Continue would mean I
would not do further testing, do you mean to suggest that you think I
couldn't come up with a single example where there would be no side effects
of changing one line in a program?

 

[Jon Skeet [C# MVP]]

Your assumptions aside that saving time using Edit and Continue would mean I
would not do further testing, do you mean to suggest that you think I
couldn't come up with a single example where there would be no side effects
of changing one line in a program?

I would rather have the unit tests all passing to tell me that that's
the case, rather than rely on my intuition and reasoning.

 

[Jon Skeet [C# MVP]]

This assumes facts not in evidence.

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

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.

And I've said that for UI work it could very occasionally be useful -
but:

1) It must have taken time to develop - and I wish that time had been
spent improving the editor

2) A feature which can be useful occasionally but is often abused isn't
a good thing usually, IMO.

(I should say at this point: programming for 20 years doesn't
necesarily indicate anything about your or anyone else's programming
ability. It's quite possible to have a lot of experience and not have
learned anything from it - I've seen that happen. I'm *not* saying
that's the case here - just that your "20 years" bit doesn't really
mean anything as far as I'm concerned.)

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.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

 

[Alvin Bruney [MVP]]

It's no secret, based on past discussion, that Jon is steadfastly against
using a debugger and would prefer unit tests. However, I use both unit tests
and E&C and I'd rather have both, E&C before unit tests of course. I like to
step, jump to next statement, change variables etc. when I am satisfied with
this, I run my unit tests. And if it's friday end of day, I skip the unit
tests. period. Reason being, the unit tests and my E&C exploration performed
the same exercise.

For any developer who uses the debugger a lot, it is a must have feature. If
you don't use the debugger and prefer unit tests, I can see why you would
think less of it.

1) It must have taken time to develop - and I wish that >time had been
spent improving the editor

I'm leary of thinly veiled attempts to discredit E&C while promoting unit
tests. like i said, i've used both and part of my job is to shove unit tests
down the throats of developers in the enterprise, but unit tests are not the
panacea that they are made out to be. neither is E&C by the way. both are
valid and should be used as appropriate.

--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin

 

[Alvin Bruney [MVP]]

I have E&C turned on but it never seems to work. Does anyone know if this
ya, that thing has never worked for me on either 03 or 05 on my laptop. in
fact i tried it today with an active x control and it promptly refused to
proceed. maybe i take a look at it tomorrow to see if i can get it up and
running. either that or unit tests. YUCK!

--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin

 

[Jonathan Wood]

Jon,

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

Well, please let me know when you hear it again. It's just about the
craziest thing I've ever heard.

And I've said that for UI work it could very occasionally be useful -
but:

And that's all I'm saying.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

Sorry, I thought I was in another group when I wrote that.

So then your argument is that we should eliminate all features that can be
abused?

 

[Michael C]

Well, I've heard people say how they do a large amount of their coding
in the debugger, so that counts as evidence to some extent.

They're exaggerating. Although I suspect they mean they spend the largest
amount of their developer time working in the debugger.

And I've said that for UI work it could very occasionally be useful -
but:

1) It must have taken time to develop - and I wish that time had been
spent improving the editor

I prefer the time saving of e&c.

2) A feature which can be useful occasionally but is often abused isn't
a good thing usually, IMO.

How much the feature is abused is a matter of opinion. I've not once opened
up someone's code and said to myself "damn e&c programmer".

(I should say at this point: programming for 20 years doesn't
necesarily indicate anything about your or anyone else's programming
ability. It's quite possible to have a lot of experience and not have
learned anything from it - I've seen that happen. I'm *not* saying
that's the case here - just that your "20 years" bit doesn't really
mean anything as far as I'm concerned.)

I agree, quite often the 20+ year programmers are worse. I had one telling
me that referetial integrity was unnecessary and a waste of time and that 0
should be used to indicate null in fks.

And yet we pretty much *have* eliminated pointers - or at least pointer
arithmetic. Their use is pretty restricted in C#, and doesn't exist at
all (unless things have changed recently) in VB.NET. Macros and
templates have gone in exactly the same way.

I was just thinking that when I read Johnathan's post that maybe pointers
should be eliminated because they are abused.

Michael

 

[Michael C]

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 used e&c alot in vb6 simply because it was taking 2 minutes to stop and
start my project in vb6 because it was so large (the 2 minutes is not an
exaggeration, I timed it). If I need to make a change that e&c doesn't allow
then I'll stop the project. I'll only ever make changes that I would have
made otherwise. I don't see why I should suffer the loss of this great
feature because someone else might abuse it.

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?

I just know newsgroups. In these arguements everyone always becomes perfect
as I said.

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?

*Maybe* the 1% of programmers who regularly do unit tests don't need e&c but
for us humans it's quite useful.

What part of database applications can't be unit tested?

I'd say it would be difficult to unit test the majority of the work I do.
However, this discussion is not about unit tests. The fact is most
developers don't unit test or don't unit test a good percentage of their
work. For these developers e&c is very useful.

Michael

 

[Michael C]

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.

That is an entirely different issue really that has nothing to do with e&c.
Once 1 part of an app is written and is first run in a workable state it
needs to be tested and have bugs fixed. Some developers will spend 10
minutes doing the testing, other's could spend 10 days or more. What you're
saying is that somehow e&c makes developers tend towards the 10 minute end
of the scale?

Michael

 

[Greg Miller]

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.

Anyone who writes bad code inside a debugger will write bad code
outside the debugger. I just recently read a blog entry (don't remember
where), but I really like the idea they put forward: "Why worry about
errors someone might make, let's concentrate on the errors we DO make."

 

[John B]

Alvin Bruney [MVP] wrote:

..I use both unit tests
and E&C and I'd rather have both, E&C before unit tests of course.

<...>

Now I'm sure I'm taking this out of context but are you saying you would
prefer E&C over a properly fleshed out suite of unit tests?


JB

 

[Jon Skeet [C# MVP]]

It's no secret, based on past discussion, that Jon is steadfastly against
using a debugger and would prefer unit tests. However, I use both unit tests
and E&C and I'd rather have both, E&C before unit tests of course.

That rules out TDD to start with.

I like to step, jump to next statement, change variables etc. when I
am satisfied with this, I run my unit tests. And if it's friday end
of day, I skip the unit tests. period. Reason being, the unit tests
and my E&C exploration performed the same exercise.

That suggests you don't properly understand the benefits of unit
testing. If you don't have tests which can be rerun at a whim, you
don't have repeatability. At that point, you don't have the extra
confidence in making changes later on that unit tests give you. If I
take someone else's code and it's got an adequate amount of unit
testing around it, I can change it and be reasonably confident that I'm
not breaking anything so long as the unit tests still pass. If the
original author only did "E&C testing" I have no such confidence.

For any developer who uses the debugger a lot, it is a must have feature. If
you don't use the debugger and prefer unit tests, I can see why you would
think less of it.

Debugger != E&C. It's important to have a debugger, even though I tend
to think that if you need to use a debugger to find out what's going
on, that usually indicates that the code isn't as readable as it should
be. I always count it as a minor defeat when I need to use a debugger.

I'm leary of thinly veiled attempts to discredit E&C while promoting unit
tests. like i said, i've used both and part of my job is to shove unit tests
down the throats of developers in the enterprise, but unit tests are not the
panacea that they are made out to be. neither is E&C by the way. both are
valid and should be used as appropriate.

The fact that you are happy to ditch unit tests and lean on the E&C
crutch when you can't be bothered to do the job properly (as I would
see it) highlights the risk of E&C as far as I'm concerned.

 

[Jon Skeet [C# MVP]]

Well, please let me know when you hear it again. It's just about the
craziest thing I've ever heard.
Sure.


Sorry, I thought I was in another group when I wrote that.

So then your argument is that we should eliminate all features that can be
abused?

Sometimes it's the right thing to do. You need to weigh up the
advantages of a feature vs the risk of abuse: how often it's likely to
be abused and the consequence of the abuse, also bearing in mind the
alternatives (such as unit testing) and how long it takes the feature
provider (MS) to implement the feature when they could be doing other
things. (It's no secret that I think the editor in VS.NET, even in
2005, is weaker than the Java editor in Eclipse. I'd rather have Open
Type and Open Resource dialogs than E&C...)

 

[Jon Skeet [C# MVP]]

I used e&c alot in vb6 simply because it was taking 2 minutes to stop and
start my project in vb6 because it was so large (the 2 minutes is not an
exaggeration, I timed it). If I need to make a change that e&c doesn't allow
then I'll stop the project. I'll only ever make changes that I would have
made otherwise. I don't see why I should suffer the loss of this great
feature because someone else might abuse it.

But don't you see how if you could have tested one piece of logic in
isolation, it wouldn't have taken 2 minutes to start? I'm unfamiliar
with the VB6 environment, so maybe it wouldn't have helped (and maybe
there isn't a decent unit testing framework available) but I'm certain
that that pain can be avoided in .NET.

I just know newsgroups. In these arguements everyone always becomes perfect
as I said.

And as I've already said, I use unit testing because I'm *not* perfect.

*Maybe* the 1% of programmers who regularly do unit tests don't need e&c but
for us humans it's quite useful.

Those who use unit tests are admitting to start with that they're
human. Unit testing isn't nearly as hard as you're implying it is. Of
course, it's easier on green-field code than testing existing legacy
code, but there are well-documented techniques for lots of nasty
situations.

I'm no super-developer. I'm a human developer who does unit testing
wholeheartedly. Why is that so hard to accept?

I'd say it would be difficult to unit test the majority of the work I do.
However, this discussion is not about unit tests.

I think they're very relevant though - if one feature makes another
almost obsolete, that makes it pretty relevant to the discussion.

The fact is most developers don't unit test or don't unit test a good
percentage of their work. For these developers e&c is very useful.

Perhaps if they hadn't been given the crutch of E&C, some of these
developers would have embraced unit testing earlier.

 

[John B]

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 ?

<...>
Wrong John but I thought I would share some of my TDD resources anyway.
The bowling Game:
http://www.objectmentor.com/resources/articleTeasers/bowling
But Uncle Bob: http://www.butunclebob.com/ArticleS.UncleBob
More Uncle Bob: http://www.artima.com/weblogs/index.jsp?blogger=unclebob
And XProgramming.com (Ron Jeffries):
http://www.xprogramming.com/Blog/Page.aspx?display=HotNeedleOfInquiry
http://www.xprogramming.com/index.htm

Also check out the included tests in the NUnit suite as it is done Test
First (I presume).

HTH
JB

 

[Jon Skeet [C# MVP]]

Anyone who writes bad code inside a debugger will write bad code
outside the debugger.

But perhaps not forever. Perhaps they'll write terrible unit tests to
start with - but they can improve.

I just recently read a blog entry (don't remember
where), but I really like the idea they put forward: "Why worry about
errors someone might make, let's concentrate on the errors we DO make."

I'd like to encourage others towards best practice, however.

 

[Jon Skeet [C# MVP]]

That is an entirely different issue really that has nothing to do with e&c.
Once 1 part of an app is written and is first run in a workable state it
needs to be tested and have bugs fixed. Some developers will spend 10
minutes doing the testing, other's could spend 10 days or more. What you're
saying is that somehow e&c makes developers tend towards the 10 minute end
of the scale?

No - E&C encourages developers to fix the problem they're looking at
*this instant* without worrying about other issues. Unit testing
encourages developers to fix the problem they're looking at while
making sure they don't break anything else that was already working.

 

[Michael C]

No - E&C encourages developers to fix the problem they're looking at
*this instant* without worrying about other issues. Unit testing
encourages developers to fix the problem they're looking at while
making sure they don't break anything else that was already working.

How exactly? I run my code and it gives me an error that an sql statement is
incorrect. I'm going to fix the sql statement either way?

Michael

 

[Michael C]

But don't you see how if you could have tested one piece of logic in
isolation, it wouldn't have taken 2 minutes to start? I'm unfamiliar
with the VB6 environment, so maybe it wouldn't have helped (and maybe
there isn't a decent unit testing framework available) but I'm certain
that that pain can be avoided in .NET.

There's only so much you can test outside the app. I'd imagine you do very
different work to me.

I think they're very relevant though - if one feature makes another
almost obsolete, that makes it pretty relevant to the discussion.

NOT IF NO ONE IS USING THAT FEATURE!!!!! Maybe object orientated databases
make relational database obsolete but no one is using them either. I know
"no one" is an exaggeration but most developers don't unit test.

Michael

 

[Jon Skeet [C# MVP]]

There's only so much you can test outside the app. I'd imagine you do very
different work to me.

You may be surprised at how much can be unit tested reasonably easily
with the right tools available (most of which are free). I dare say we
do do different work, and there are certain areas which are indeed very
difficult to unit test, but I would hope that in most applications
those areas would be in the minority.

NOT IF NO ONE IS USING THAT FEATURE!!!!! Maybe object orientated databases
make relational database obsolete but no one is using them either. I know
"no one" is an exaggeration but most developers don't unit test.

I believe that situation is changing - certainly in the Java world,
unit testing is becoming more and more prevalent. Most of the
well-respected open source frameworks and libraries in Java come with a
comprehensive set of unit tests, for instance. I believe this situation
will be more and more the case in .NET as well - although it would have
been accelerated by Microsoft including unit testing in all editions of
VS.NET

However, that rate of progress will be further diminished by people
leaning on the crutch of E&C, I believe.

Jon