c# 2004 (Whidbey)

[Arman Oganesian]

Just finished reading about upcoming features in 2004
version of VS.NET and C# in particular
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#
whidbey
Looks good and I am very happy (about generics, split
types...), Except 1 thing
Microsoft is reintroducing the "Edit and continue" future
for VB.NET ONLY????
The "Edit and Continue" functionality in debugger is NOT
about simplicity, but about having a modern and powerful
debugger(tester) which saves a LOT of time in testing the
code(I remember in good old times with vb I would write
only the first line of the method, then put it into
debugging mode and continue until it was all finished), it
was available in C++.NET, it's included in ALL
modern Java IDEs(JBuilder..), and now it's back to VB.NET,
by that making the Visual C#.NET the only modern and
popular language with half debugger??
Please someone from Microsoft tell me that I am wrong.
If it can be done for VB and C++, then I will not by any
explanation, why it can't be done for c#
Thank you

 

[Bob Grommes]

Sure, "Edit and Continue" can be implemented in C# as well as in VB. VB
users demand it as they were accustomed to it in VB6, but according to MSFT,
C# users are more ambivalent about it. A minority want it, a minority think
it's a Bad Thing, and most don't really care. Personally I fall into the
"don't care" camp with suspicions that it could be a Bad Thing, although I'm
trying to remain open-minded about it. I guess my thinking is, I've gotten
along fine without it for 20 years, and besides, I think it's healthy and
useful to work code out in your head and via "desk-checking" before you ever
execute it. Good debugging practice says you step through every line of
code anyway at some point before release.

Now, I'm fully aware that I'm generalizing. A tool isn't necessarily bad
just because it's capable of being misused or because it helps the witless
get farther along before they go down in flames. And as much as long-time
VB developers miss the feature, perhaps there's something to it. I just
haven't seen a compelling need for it in my own work, nor have I ever had a
desire to execute code line by line as I write it.

Anyway, bottom line, from what I've read, MSFT is saying publicly if enough
C# developers demand edit-and-continue, they'll implement it -- but it's not
trivial to implement, and they don't want to expend resources on it when C#
developers seem to be clamboring for other things.

--Bob

 

[Colin Young]

VB developers miss the feature, perhaps there's something to it. I just
haven't seen a compelling need for it in my own work, nor have I ever had a
desire to execute code line by line as I write it.

I don't think that's what is meant by "debug and continue." D&C is the
ability to break on an error, change the code and have the debugger start up
again from the same point in the program, with all variables, etc. in the
same state as before the break.

Colin

 

[Arman Oganesian]

I absolutely agree with you that one should workout the app
in the head before start coding, in fact for a last year
and a half I've been using the Rational XDE with VS.NET
and I've got used to it so match that even if I need to
create 4-5 classes, first I will do it with UML, then
generate the stub, and then continue(In fact another
missed capability from VS.NET, when you compare XDE with
Visio, then Visio is just a joke, you can't do a serious
design with it, and since the Rational has become part of
the IBM's software group, for which destroying VS.NET is
the job # 1, I wonder what is Microsoft is going to do
about it, since all good IDEs include some advanced case
tool capabilities, even new C#Builder will come with it
based on Together Control Center, and now imagine if IBM
drops XDE from VS.NET?, I will be the first one to move to
C#Builder)
But back to "Edit and continue", it is not anymore an
exclusive VB feature, yes it was pioneered in the VB but
now C# will be the only major tool without it, and it is
a huge productivity enhancement, just imagine you have a
Web app with some security already implemented, and you
can't just simply select the page you work on as a start
up page, it will send you to login first, and any time you
need to make a small fix to code you have to start all
over again, and many similar situations.
I think it is a lame excuse for Microsoft say that if not
to many developers demanding it then we will not include
it, many C# developers are not familiar with it or as you
don't really care about it because did not use it before,
the Java people didn't ask for it too, but
It is included in all major Java IDEs for a last year and
a half, because it's a great productivity enhancer and
saves a lot of time, and now when C# and Java are going
neck to neck, whoever makes better tools may attract more
people.
I know it's not easy thing to do, in Java for example I
believe the technology behind it called "Hot Swap",
basically being able to replace piece of compiled code on
the fly,
I would think that they did something similar forVB.NET
(MSIL?)so most of it should be already done, and believe
me once you start using it and saving the time, you will
agree that any modern Language/IDE/Debugger should not be
released without it
Arman

 

[ncaHammer]

Hi Arman,
Very good points !

(In fact another
missed capability from VS.NET, when you compare XDE with
Visio, then Visio is just a joke, you can't do a serious
design with it,

IMHO you don't have to compare Visio with anything to decide that is a joke

and since the Rational has become part of
the IBM's software group, for which destroying VS.NET is
the job # 1, I wonder what is Microsoft is going to do
about it, since all good IDEs include some advanced case
tool capabilities,
http://www.eweek.com/article2/0,3959,1202588,00.asp

I think it is a lame excuse for Microsoft say that if not
to many developers demanding it then we will not include
it,

Yes, i was puzzled too, unbelievable statement

I know it's not easy thing to do, in Java for example I
believe the technology behind it called "Hot Swap",
basically being able to replace piece of compiled code on
the fly,

some Java IDE(s) (cant remember which) already have reverse execution, (that
may require an IL interpeter) but to see this in VS we may have to wait too
long (is not even at MS research labs)

I would think that they did something similar forVB.NET
(MSIL?)so most of it should be already done, and believe
me once you start using it and saving the time, you will
agree that any modern Language/IDE/Debugger should not be
released without it

Amen

 

[Alvin Bruney]

read this thread in here about what C# needs

 

[Alvin Bruney]

Edit and Continue will get implemented in C# VS.NET when Borland decides to
implement it first in there new ide. Then you will see microsoft scramble to
put it in despite the junk they are talking now. It's all about competition.
And the better product.

 

[Alvin Bruney]

Niall,
you are joking right? say it aint so. What company do you work for? what
software do they produce? i hope it aint airplane software.

 

[Bill Priess]

With E&C (and I have seen this happen...), you change something in function
foo that returns an integer. In doing so, other functions that rely on
function foo do not get updated and start returning the wrong values, so,
you break again and change the other functions to return the new values,
when low and behold, you break more functions.

Call me crazy, but I would rather start over from scratch and make sure
that if I change one function, it doesn't cascade up the line and break 10
others. with E&C, the compiler doesn't check to make sure that all uplevel
functions are receiving the correct value. That is the responsibility of
the developer and a lot of developers that I know don't take the time to
even learn what System.Diagnostics.Debug.Assert is or does... but that is
for another thread...

Bill P.

 

[Alvin Bruney]

it's good that you can clarify your position. but i bring you back to your
original post which says you don't bother to step thru code that you write.

Why make the effort to step
through

instead you rely on unit tests. unless you know the code, the other guy in
the testing dept. cannot write a unit test to test every line of code you
write. unless you yourself are writing the unit tests, you cannot guarantee
that the unit tests will test your freshly written code.

unit tests are only as good as the effort you put into writing it. Unit
tests typically flag failures only. that is, did the button click do what it
was supposed to? Yes/No. It typically DOES NOT check to see if the routine
returned junk. I can count the number of times scripts were run against
newly written code which passed with flying colors but spat out nothing but
junk first thing in the morning. If you aint stepping thru your code, you
are taking chances.

unit tests or smoke screen tests are they are sometimes called are great but
they find most of their importance in regression testing. that's not what
you said. you said you don't verify the code you write. you rely on someone
else to write a unit test to test it for you. i won't be flying on your
airplane!

 

[Niall]

I talked a lot about writing the unit tests before you actually write the
code you need, whereas you are talking about writing the code and then
getting someone else to test it. Unit tests only properly function as a
contract and a proper test if they are written first. Otherwise, you are
taking a potshot at what you think should be tested, and you can miss
things.

So going back to where I mentioned writing the tests first, and using them
as a contract, then it's always the same coder that writes the test and the
code. It's very bad practice to write some code and then tell someone else
to write the test. The idea of unit testing is to get you to actually work
out what you want the code to do before you write it, and then document the
desired behaviour in a contract that can be run against the code to see if
the contract is actually fulfilled.

So if you don't write the test first, how do you know what you actually want
the code to do? And if you say "because I have already worked it out in my
head", then you should take what you've worked out in your head and put it
into a unit test. Then you start coding, and when the test passes, you are
finished.

Tests should be complete, not just "did it thrown an exception? No? Then it
worked fine". You can use coverage profilers at line level to ensure that
your tests are doing things like testing every possibility in an if
statement/case statement, actually getting into the bodies of loops, etc. If
you have code in your function which is not covered by your unit test, then
you have written some functionality into the function which you never worked
out a plan (read contract) for. So how do you know it's what you really want
if you never made a contract for it? If you do know exactly what it should
be doing, then that should be in the test.

It all comes back to this: everything in the function should be tested by
its unit test. If this isn't true, you have designed the function badly, and
there is the potential for errors. I never said I rely on someone else to
write my tests for the code I have written, because doing that shows that I
wrote my code without working out a clear list of requirements for it.

If I asked a coder for aeroplane software "How do you know your software
works properly", and they said "because I stepped through the code a few
times, and we have a checkin policy where a team leader is required to look
at the code and give it the ok before it's checked in", then I would be
worried. Code is a fluid, dynamic thing, simply stepping through it
occasionally only guarantees that it is working at that explicit point in
time. The only way such a developer could convince me that the software was
safe for me right now would be to step through every line of code at that
instant and show that it all works 100%. Because otherwise you have no idea
whether the function that was checked a year, a month, a week, a day, an
hour ago still works with the latest version of other areas of the code.

That's exactly what unit tests do for you, automatically, and thousands of
times faster. If a client asked us "How can you guarantee that your code is
working 100% right now?", then I would fire up the unit test form and hit
Run. We currently have around 6000 tests (this goes up around a hundred or
so a day at present), and this takes about 10 minutes. Could you desk check
your entire system in 10 minutes? And hence, could you have the entire
system being continually, repeatedly desk checked every 10 minutes, 24/7 so
that any errors are caught within 10 minutes?

Of course, it is possible that bad programmers write bad tests, just as it's
possible that programmers without unit tests forget/decide not to step
through their code, or when they do, they don't do it properly. But if you
are perseverent and vigilant, I think the benefits of unit testing are
important and valuable.

Niall

Hmm.. this was a little long

 

[Niall]

I have just re-read your reply. I'm not sure that you and I both have the
same idea of the meaning of "unit tests". What I am talking about are
functions that are written with the code that it is testing, which use your
object, call the function with the combinations of parameters that ensure
that all possible requirements are tested. You use something like an
assertion to check that what the function returns or does to the object's
state is what you are expecting. So you end up with 1 or more (usually
around 10 or so) assertions of expected behaviour for each test. Then you
can run that test whenever you want and see the result.

I'm not talking about user acceptance testing which goes like "When I click
this button, I should get a report", and someone will take the list of
expected behaviours and run through and go Pass/Fail on each test. I see
these as the contract between the customer and the developer. The unit tests
are the contract between the developer(s) and their code, at a much lower
level.

So you want a square root function. You write a test (before you write the
square root function) saying that when you call the function with 4, you
expect 2. When you call it with 9, you expect 3, when you call it with 2,
you expect 1.41etc. When you give it a negative number, you expect a
particular type of exception. Later on, if someone comes along to refactor
the code to make it faster, they make their change and run the test. If it
passes, all is good. If it doesn't, you see that the result you got from
sqrt(9) was 5, and something is looking a bit fishy

Basically unit tests, as I use the term, are used to design by contract,
such that if the code is not behaving according to the contract, then that
fact becomes known instantly. It's similar to the preconditions,
postconditions and invariants which Eiffel touts.

Niall

 

[Jon Skeet]

it's good that you can clarify your position. but i bring you back to your
original post which says you don't bother to step thru code that you write.


instead you rely on unit tests. unless you know the code, the other guy in
the testing dept. cannot write a unit test to test every line of code you
write.

Which "other guy" are you talking about?

unless you yourself are writing the unit tests, you cannot guarantee
that the unit tests will test your freshly written code.

Where do you get the idea that Niall *isn't* writing the unit tests
himself?

unit tests are only as good as the effort you put into writing it.

That's true of everything - but I'd rather put effort into unit testing
properly than into stepping through code properly once.

Unit
tests typically flag failures only. that is, did the button click do what it
was supposed to? Yes/No. It typically DOES NOT check to see if the routine
returned junk.

In that case you've seen very badly written unit tests. Note that "do
what it was supposed to" for me includes "it didn't return junk".

I can count the number of times scripts were run against
newly written code which passed with flying colors but spat out nothing but
junk first thing in the morning. If you aint stepping thru your code, you
are taking chances.

If you're stepping through your code once and then assuming it's okay
thereafter without automated tests, you're taking chances too. Spending
the same amount of time writing unit tests as stepping through the code
will usually prove to be far more valuable, in my experience.

Bear in mind that in order to step through your code in all possible
types of circumstances, you probably need to effectively write most of
the unit tests anyway. I remember writing a piece of code recently
where it took longer (and more lines of code) to write the unit tests
than for the code it was testing. However, those tests caught some bugs
which I probably *wouldn't* have caught just by stepping through the
code a few times, even if I'd stepped through every line.

unit tests or smoke screen tests are they are sometimes called are great but
they find most of their importance in regression testing. that's not what
you said. you said you don't verify the code you write. you rely on someone
else to write a unit test to test it for you.

Where did Niall say that someone *else* would be writing the unit
tests? Typically it's the person writing the code who writes the unit
tests in the first place.

i won't be flying on your airplane!

To be honest, and only in terms of this conversation, I'd rather fly on
Niall's than yours...

 

[Alvin Bruney]

What you are describing is XP programming? isn't it? So we are on the same
track. I am yet to be convinced that this approach to programming is
profitable, all things considered. Here is a link.
http://www.extremeprogramming.org/. I think the gist of your argument was
you would rather unit test than step thru your code. My response was no,
that's wrong. you absolutely must step thru every line of code you write. no
excuses. sure go ahead and unit test all you want to, that's part of it as
well - a large part too, but you seemed to not want to step thru written
code.

In addition, i think you went way off course by thinking that if you changed
line 10,428 in source code that you needed to step thru all previous lines
of code. The assumption was you already stepped thru these lines of code
when you first wrote them, you now need to step thru line 10,428 which is
the line you just changed. Use unit tests to regression test the previous
lines of code.

 

[Alvin Bruney]

Which "other guy" are you talking about?

I thought he meant someone in the testing dept wrote the unit tests. This is
what we did at the last company I worked at. And it was perfectly useless,
clumsy and required way too much co-ordination. It may work with 30 - 30
programmers like what Nial is saying, but not 400 as in the last company i
worked for.

Where do you get the idea that Niall *isn't* writing the unit tests
himself?


That's true of everything - but I'd rather put effort into unit testing
properly than into stepping through code properly once.

You missed the point. I didn't, or can't remember saying I wouldn't unit
test. In fact, I didn't say that! what i had a gripe with was Nial saying he
didn't step thru written code instead relying on unit tests to fish out
bugs. That is wrong and will always be wrong. Every line of written code
must be stepped thru in the debugger. There is no compromise on this. none
at all. You can unit test before after or during the process. I encourage
it.

Where did Niall say that someone *else* would be writing the unit
tests? Typically it's the person writing the code who writes the unit
tests in the first place.

No, that's not even the recommended way. In my case, unit tests were
prepared by the testing department. We were made to participate in a one day
seminar by some expert who taught that this was the recommended way to
proceed. Hence it was an assumption on my part based on my experience.

To be honest, and only in terms of this conversation, I'd rather fly on
Niall's than yours...

to each his own. include me in your will.

 

[Alvin Bruney]

I'm confused now.
What is the point of doing both unit tests and stepping thru a debugger then
(on corporate time that is)? What would one method uncover that the other
one won't since they are in fact doing the exact same thing - assuming that
you spent the day writing a unit test to examine every line of code (which
is feasible but very impractical). Seems like we all ought to go with Nial's
suggestion and forget about the debugger and just rely on unit tests to keep
the airplane from hitting the mountain.

Case in point. My function takes a date string examines it, returns a
formatted string or empty if the date is bogus. There are many ways to enter
bogus dates obviously. Would your unit test, generate every possible bogus
date? No? A subset of bogus dates maybe? Well you are flying blind hoping
that the date entered was a date your unit test actually used. Is it not
easier to flush out this bug by examining what the string looks like in a
debugger? It's now easy to tell how your function can handle it for every
possible case. Not the best case in point but sufficient to demonstrate what
I am thinking.

That mountain sure looks close to us now. wonder if the date string the
pilot entered was tested.

 

[Jon Skeet]

I'm confused now.
What is the point of doing both unit tests and stepping thru a debugger then
(on corporate time that is)?

I generally only step through in a debugger when I don't understand
what's going on - eg if there's a bug.

What would one method uncover that the other
one won't since they are in fact doing the exact same thing - assuming that
you spent the day writing a unit test to examine every line of code (which
is feasible but very impractical).

In order to step through every line, you'd have to set up the
appropriate conditions in the first place. If you can set up those
conditions, unit test them - then you can do it repeatably.

Seems like we all ought to go with Nial's
suggestion and forget about the debugger and just rely on unit tests to keep
the airplane from hitting the mountain.

Forget about the debugger for stepping through code which you believe
to be correct. Keep it for code which isn't working how you expect it
to.

Case in point. My function takes a date string examines it, returns a
formatted string or empty if the date is bogus. There are many ways to enter
bogus dates obviously. Would your unit test, generate every possible bogus
date? No?

No, nor would you step through in a debugger for every possible bogus
date. However, you can still make sure your unit test covers every line
of code.

A subset of bogus dates maybe? Well you are flying blind hoping
that the date entered was a date your unit test actually used.

Likewise if you're stepping through the debugger.

Is it not
easier to flush out this bug by examining what the string looks like in a
debugger?

Only if you know in advance which string is actually a bug.

It's now easy to tell how your function can handle it for every
possible case. Not the best case in point but sufficient to demonstrate what
I am thinking.

I don't think it is, actually - you haven't really demonstrated a case
where stepping through in the debugger would have helped.

That mountain sure looks close to us now. wonder if the date string the
pilot entered was tested.

Of course, you haven't actually given any evidence that your code is
safer than Niall's.

 

[Niall]

What you are describing is XP programming? isn't it? So we are on the same
track. I am yet to be convinced that this approach to programming is
profitable, all things considered. Here is a link.
http://www.extremeprogramming.org/. I think the gist of your argument was
you would rather unit test than step thru your code. My response was no,
that's wrong. you absolutely must step thru every line of code you write. no
excuses. sure go ahead and unit test all you want to, that's part of it as
well - a large part too, but you seemed to not want to step thru written
code.

In addition, i think you went way off course by thinking that if you changed
line 10,428 in source code that you needed to step thru all previous lines
of code. The assumption was you already stepped thru these lines of code
when you first wrote them, you now need to step thru line 10,428 which is
the line you just changed. Use unit tests to regression test the previous
lines of code.

In this case, you need unit testing as you say. If you didn't have unit
testing, you'd have no idea whether the rest of the system still works after
you change your code. The thing is... if you're prepared to use unit testing
for ensuring the safety of the whole of the system when central code is
changed, why are you not prepared to use it to ensure the safety of the code
that you're actually changing. Ideally, if there's a bug, you should write a
test which fails because of the bug, and then fix it.

If you do this, you get three benefits. Firstly, you can be certain you
fixed the bug, because if you didn't, the test would fail. Secondly, you
make sure that if someone comes along and changes the code such that the bug
returns, then the test will catch that. So you've fixed the bug for now, but
also ensured it remains fixed in future. Thirdly, you get a documentation of
the bug in the forms of a new requirement (which was previously missing), so
you further define the specifications of your code.

Niall

 

[Niall]

I thought he meant someone in the testing dept wrote the unit tests. This is
what we did at the last company I worked at. And it was perfectly useless,
clumsy and required way too much co-ordination. It may work with 30 - 30
programmers like what Nial is saying, but not 400 as in the last company i
worked for.
....

No, that's not even the recommended way. In my case, unit tests were
prepared by the testing department. We were made to participate in a one day
seminar by some expert who taught that this was the recommended way to
proceed. Hence it was an assumption on my part based on my experience.

If this person giving the seminar was talking specifically about XP, then I
think he wasn't very expert, as Jon has said. The idea of unit testing in XP
seems to be that you use the tests to give you the requirements for your
code, helping you evolve the design, and you get automated testing for free.
The XP idea is that you are supposed to write the unit tests before you
write any of the actual code. They even go so far as to recommend you write
the test before it will even compile (because you haven't even declared the
actual function).

So... writing unit tests after you have written the code, and especially
getting someone who isn't involved in the coding of the original function to
write the tests afterward is a very bad thing. That person could have no
idea, or not enough of an idea of what you're doing, and hence not write
tests that fully cover your code. This is why the tests are more useful if
they come first: by writing the test, you then know what you're doing in the
function.

The only way I could see unit testing working when there is a coder (or
coders) and a tester who is completely uninvolved in the coding would be if
the tester is the one that knows what the function should be doing, and they
write the test for the coder as a specification before the coder begins
their work.

Niall

 

[Alvin Bruney]

One final question. And this would be the final one.
You
actually
seriously
no jokingly
the-boss-is-not-over-your-shoulder-so-you-can-speak-freely

write unit tests before you start to write code?
write unit tests before you start to debug broken code?

if this is true you need a medal. plain and simple.
waiting for that serious reply.

PS. If it is any consolation Skeet doesn't do unit tests before he fires up
the debugger either. He says so on his website ;-)