473,320 Members | 2,124 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

C# & VB-> General Questions

C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot be
done in VB? it says ...."read-only" during runtime......

2. Why does vb automatically show the errors, but C# i have to build the app
b4 errors are underlined in my code?
Nov 21 '05 #1
55 1737

"Hareth" <ab******@hotmail.com> wrote in message
news:ud**************@tk2msftngp13.phx.gbl...
C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot be
done in VB? it says ...."read-only" during runtime......

2. Why does vb automatically show the errors, but C# i have to build the
app b4 errors are underlined in my code?


The C# portion of the IDE does not support such a robust real time check
system that vb.net has to be able to show the errors in your code. Syntax
errors will immediatley show up in the IDE but Type checking errors will not
be caught until a compile is done.
Nov 21 '05 #2

"Hareth" <ab******@hotmail.com> wrote in message
news:ud**************@tk2msftngp13.phx.gbl...
C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot be
done in VB? it says ...."read-only" during runtime......

Its a confuration option, but for the life of me I can't figure out how to
change it.
2. Why does vb automatically show the errors, but C# i have to build the
app b4 errors are underlined in my code?


VB uses a background compiler to compile and analyze your code as you write
it, C# does not. Thus VB provides better errors but it can bog down as
projects get very large.
Nov 21 '05 #3
The teams that built the IDE interfaces for C# and VB are different groups
of people. They implemented feature sets that are different in some
respects, based on their notions of what their developers would want. The VB
group apparently thought that the editor should show errors immediately,
while the code was being typed - it's more like VB6, and I must say that
that it's pretty handy, to boot. The C# group apparently thought that their
developers would be coming from C++, where the VS6 IDE gives them
essentially no real-time help. They probably thought that their developers
would disdain that kind of hand-holding. You know: "REAL programmers don't
need squigglies!"

I've heard that in the next go-round, VB.Net will get edit-and-continue,
while the C# group won't implement that. It's a shame that the C# people
won't have that useful capability. In VB6, it sometimes saved me
considerable time during development, but my impression is that some fairly
vocal people in the C# developer community don't want it for some reason I
can't fathom. I suspect that it's because they've never had it, and don't
want to admit that something from the so-called 'toy language' would be
useful to them. (Could it be that C# programmers are Republicans, and like
Republicans have already had all the ideas they ever want to have?) I mostly
program in C# these days, myself, and I'd love to have it in that
environment.

What I hope will happen in the next iteration of the tools is that each
group will learn something useful from the other. The VB.Net people get some
goodies from the C# camp, and the C# people get some from the VB.Net side.
If everyone can rise above their ego problems, maybe it'll get better for
all of us (and, in particular, for those of us who program regularly in both
languages!).

Tom Dacon
Dacon Software Consulting

"Hareth" <ab******@hotmail.com> wrote in message
news:ud**************@tk2msftngp13.phx.gbl...
C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot be
done in VB? it says ...."read-only" during runtime......

2. Why does vb automatically show the errors, but C# i have to build the
app b4 errors are underlined in my code?

Nov 21 '05 #4

"Tom Dacon" <td****@community.nospam> wrote in message
news:eg**************@TK2MSFTNGP10.phx.gbl...
The teams that built the IDE interfaces for C# and VB are different groups
of people. They implemented feature sets that are different in some
respects, based on their notions of what their developers would want. The
VB group apparently thought that the editor should show errors
immediately, while the code was being typed - it's more like VB6, and I
must say that that it's pretty handy, to boot. The C# group apparently
thought that their developers would be coming from C++, where the VS6 IDE
gives them essentially no real-time help. They probably thought that their
developers would disdain that kind of hand-holding. You know: "REAL
programmers don't need squigglies!"
There are issues in the two. Background Compilation has drawbacks and does
not really suit for large projects. Search the groups and you'll find plenty
of VB users complaining about how slow the IDE is when they are working in
huge projects.
I've heard that in the next go-round, VB.Net will get edit-and-continue,
while the C# group won't implement that. It's a shame that the C# people
won't have that useful capability. In VB6, it sometimes saved me
considerable time during development, but my impression is that some
fairly vocal people in the C# developer community don't want it for some
reason I can't fathom. I suspect that it's because they've never had it,
and don't want to admit that something from the so-called 'toy language'
would be useful to them. (Could it be that C# programmers are Republicans,
and like Republicans have already had all the ideas they ever want to
have?) I mostly program in C# these days, myself, and I'd love to have it
in that environment.

Apparently you havn't been paying attention, the C# team has announced E&C
support despite the concerns expressed by a fair portion of the community.
It seems that the pro-E&C crowd whines well, even though I've yet to hear a
*single* reason why E&C is worth anything. Everything is just rhetoric, "VB6
had it and I want it back", or plain BS.

And the isuse with it isn't so much that its from VB, just that it reduces
code quality. VB6 may well have been a more reliable and less disdained
langauge if its users weren't so keen on using E&C for every bug they ran
across(and don't claim otherwise, I somehow doubt anything beyond a small
minority actually didn't use it to fix things inappropriatly). It simply
does not add to the quality of code and is far to expensive for the only
real use it has(fixing minor typos. Fixing a bug in E&C is downright
foolish). But thats all been documented many times over.

However, your political opinions are really off topic, and the rest of your
opinions are rather rude. If you are going to spout opinion off it would
suit to actually *READ* wahts been said instead of defining peoples
motivations based entirely on what suits your purposes. E&C is an expensive
tool that doesn't belong in *any* language, but, again, that is well
documented if you would take the time to read it.
What I hope will happen in the next iteration of the tools is that each
group will learn something useful from the other. The VB.Net people get
some goodies from the C# camp, and the C# people get some from the VB.Net
side. If everyone can rise above their ego problems, maybe it'll get
better for all of us (and, in particular, for those of us who program
regularly in both languages!).

Tom Dacon
Dacon Software Consulting

"Hareth" <ab******@hotmail.com> wrote in message
news:ud**************@tk2msftngp13.phx.gbl...
C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot be
done in VB? it says ...."read-only" during runtime......

2. Why does vb automatically show the errors, but C# i have to build the
app b4 errors are underlined in my code?


Nov 21 '05 #5
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should
have sprinkled some smileys around my comments to put across the notion that
I was aiming at irreverence rather than vitriol. In any case, I don't agree
with your responses, although I respect your right to hold them.

As to edit-and-continue, surely you do deep-path inspection of your code
during testing, don't you? Isn't it a pain when you're deep in a debugging
session, hit a show-stopper, and have to exit the session, fix the bug, and
then reconstruct the whole testing scenario back down to that point again
before you can continue? Sometimes you can save the situation right there
and proceed. Saves a lot of time. Of course it doesn't always work that way,
but every once in a while you gain from its presence. I missed hearing that
the C# team has decided to do it - thanks for correcting me - but I'm
delighted to hear it. Try it some time, when you get it in a version of
VS.Net that supports it. Might change your mind. Myself, I'd make it an IDE
option, that you can turn off if it's causing you performance problems, so
if for some reason you need to load the whole world in your solution you can
avoid whatever difficulties its presence induces. Instead of loading the
whole world, though, why not try thorough testing of the lower-level
assemblies, to the point where you trust them (think NUnit and its
brethren), and then just reference them and use them as binaries from the
part of the code that you're currently working on?

But much more important, perhaps you missed my last paragraph, in which I
presented a hope that the two camps might come somewhat closer together,
rather than holding such deep investment in a single way of doing things. I
often see this in people who have never known anything other than a single
programming language, and therefore believe that the way it does things is
the only right way to do them. These are usually young programmers, in the
early stages of their careers, to whom exposure to other ways of doing
things hasn't yet given a wider perspective. I wouldn't think you could get
to be an MVP without being a rather experienced developer, and unless C++ is
the only language you've ever known before C#, and unless you have had no
experience in any other development environments, I'd expect you to have a
balanced viewpoint as well. Do I misunderstand?

Best regards,
Tom Dacon
Dacon Software Consulting
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2***************@TK2MSFTNGP09.phx.gbl...

"Tom Dacon" <td****@community.nospam> wrote in message
news:eg**************@TK2MSFTNGP10.phx.gbl...
The teams that built the IDE interfaces for C# and VB are different
groups of people. They implemented feature sets that are different in
some respects, based on their notions of what their developers would
want. The VB group apparently thought that the editor should show errors
immediately, while the code was being typed - it's more like VB6, and I
must say that that it's pretty handy, to boot. The C# group apparently
thought that their developers would be coming from C++, where the VS6 IDE
gives them essentially no real-time help. They probably thought that
their developers would disdain that kind of hand-holding. You know: "REAL
programmers don't need squigglies!"


There are issues in the two. Background Compilation has drawbacks and does
not really suit for large projects. Search the groups and you'll find
plenty of VB users complaining about how slow the IDE is when they are
working in huge projects.

I've heard that in the next go-round, VB.Net will get edit-and-continue,
while the C# group won't implement that. It's a shame that the C# people
won't have that useful capability. In VB6, it sometimes saved me
considerable time during development, but my impression is that some
fairly vocal people in the C# developer community don't want it for some
reason I can't fathom. I suspect that it's because they've never had it,
and don't want to admit that something from the so-called 'toy language'
would be useful to them. (Could it be that C# programmers are
Republicans, and like Republicans have already had all the ideas they
ever want to have?) I mostly program in C# these days, myself, and I'd
love to have it in that environment.


Apparently you havn't been paying attention, the C# team has announced E&C
support despite the concerns expressed by a fair portion of the community.
It seems that the pro-E&C crowd whines well, even though I've yet to hear
a *single* reason why E&C is worth anything. Everything is just rhetoric,
"VB6 had it and I want it back", or plain BS.

And the isuse with it isn't so much that its from VB, just that it reduces
code quality. VB6 may well have been a more reliable and less disdained
langauge if its users weren't so keen on using E&C for every bug they ran
across(and don't claim otherwise, I somehow doubt anything beyond a small
minority actually didn't use it to fix things inappropriatly). It simply
does not add to the quality of code and is far to expensive for the only
real use it has(fixing minor typos. Fixing a bug in E&C is downright
foolish). But thats all been documented many times over.

However, your political opinions are really off topic, and the rest of
your opinions are rather rude. If you are going to spout opinion off it
would suit to actually *READ* wahts been said instead of defining peoples
motivations based entirely on what suits your purposes. E&C is an
expensive tool that doesn't belong in *any* language, but, again, that is
well documented if you would take the time to read it.
What I hope will happen in the next iteration of the tools is that each
group will learn something useful from the other. The VB.Net people get
some goodies from the C# camp, and the C# people get some from the VB.Net
side. If everyone can rise above their ego problems, maybe it'll get
better for all of us (and, in particular, for those of us who program
regularly in both languages!).

Tom Dacon
Dacon Software Consulting

"Hareth" <ab******@hotmail.com> wrote in message
news:ud**************@tk2msftngp13.phx.gbl...
C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot
be done in VB? it says ...."read-only" during runtime......

2. Why does vb automatically show the errors, but C# i have to build the
app b4 errors are underlined in my code?



Nov 21 '05 #6
Tom Dacon <td****@community.nospam> wrote:
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should
have sprinkled some smileys around my comments to put across the notion that
I was aiming at irreverence rather than vitriol. In any case, I don't agree
with your responses, although I respect your right to hold them.

As to edit-and-continue, surely you do deep-path inspection of your
code during testing, don't you? Isn't it a pain when you're deep in a
debugging session, hit a show-stopper, and have to exit the session,
fix the bug, and then reconstruct the whole testing scenario back
down to that point again before you can continue? Sometimes you can
save the situation right there and proceed. Saves a lot of time. Of
course it doesn't always work that way, but every once in a while you
gain from its presence. I missed hearing that the C# team has decided
to do it - thanks for correcting me - but I'm delighted to hear it.
Try it some time, when you get it in a version of VS.Net that
supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.

I'll probably find it useful when viewing a UI, so that I can change a
few behavioural things to see what feels best as a user, but as a way
of debugging I think it leaves a lot to be desired.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #7
Hi Tom,

Daniel has participated in some long-ish discussions recently on the
'negative' aspects of Edit-and-continue. If you search the newsgroups on
Google using his name and the term E&C, you will probably stumble across the
discussion.

Personally, I agree with you that E&C is useful (as you will see... I
engaged Daniel in that aforementioned discussion). I do not suggest
pursuing that discussion in this thread as well.
Goodness - ruffled a C# feather, didn't I? His remarks were hardly less offensive than yours... don't sweat it.
But much more important, perhaps you missed my last paragraph, in which I
presented a hope that the two camps might come somewhat closer together,
rather than holding such deep investment in a single way of doing things.
Microsoft is more concerned with marketing to the respective groups than it
is in religious battles. If a language has a feature, it's because the
developers of that language spoke with the users and decided that the
feature was desirable. From what I've seen of the new version, there's a
lot more in common between the two languages this time, although VB has
added some interesting short-cuts aimed at VB6 developers that still haven't
switched.
I wouldn't think you could get
to be an MVP without being a rather experienced developer, and unless C++ is the only language you've ever known before C#, and unless you have had no
experience in any other development environments, I'd expect you to have a
balanced viewpoint as well. Do I misunderstand?


Let's all hope for balance in our viewpoints, and a fair and respectful
consideration of the ideas of others.

A little humor is nice too.
--- Nick


Nov 21 '05 #8

"Tom Dacon" <td****@community.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should
have sprinkled some smileys around my comments to put across the notion
that I was aiming at irreverence rather than vitriol. In any case, I don't
agree with your responses, although I respect your right to hold them.
And,likewise, I don't agree with your responses, but you do have the right
to have them

As to edit-and-continue, surely you do deep-path inspection of your code
during testing, don't you? Isn't it a pain when you're deep in a debugging
session, hit a show-stopper, and have to exit the session, fix the bug,
and then reconstruct the whole testing scenario back down to that point
again before you can continue? Sometimes you can save the situation right
there
And you really think that test is trustworthy? Does changing code so thta it
works with the current state any indication that it is going to work with
other state? Does it pass the covering unit tests? Once you modify the
method your test run is tainted, IMHO, and its worthless to go on. You will
waste more time testing future parts that may break the next time around
because the fix didn't work.

Fixes should not be done on the fly. The errant code should be considered,
the cause of the code needs to be considered, then a fix devised, documented
if you do so, and applied. After that test coverage applied again. Simply
fixing something until you think it works and then moving on is not terribly
safe to my mind.

Again, this comes back to typos. The only bug you could realistically fix
would be a mistype in an SQL statement or xpath statement and E&C is like
using $100,000 whiteout to do so when you could fix the typewriter instead.
It really is the wrong thing to be focusing resources on, code authoring(not
the author, mind you) needs to be enhanced. IDE's simply do not provide
enough support for embedded langauges.

The greater evil is code edited in E&C mode so the user doesn't have to
break out of his debug session to fix a problem. I worry about seeing code
which was obviously formed out of the desire to stop debugging. I know many
people say they will go back and fix it, and even that they usually do, but
even if 5% of those occurances are not fixed the quality of the code as a
whole is going to drop substantially.
and proceed. Saves a lot of time. Of course it doesn't always work that
way, but every once in a while you gain from its presence. I missed
hearing that
Ok, the rare occasion happens where it comes in handy, all and good, except
waht did it cost? Did you maybe lose something that you would have used
every day for something that you might use once a week? A month? Does the
cost of such a feature justify its use?
the C# team has decided to do it - thanks for correcting me - but I'm
delighted to hear it. Try it some time, when you get it in a version of
VS.Net that supports it. Might change your mind. Myself, I'd make it an
IDE
I don't think I will, thank you. I have little need for it.
option, that you can turn off if it's causing you performance problems, so
if for some reason you need to load the whole world in your solution you
can avoid whatever difficulties its presence induces. Instead of loading
the whole world, though, why not try thorough testing of the lower-level
assemblies, to the point where you trust them (think NUnit and its
brethren), and then just reference them and use them as binaries from the
part of the code that you're currently working on?
I assume this is meant to address background compilation moreso than E&C. As
far as that goes, I don't know if VB offers a way to turn it off, I just
know it causes some trouble. Personally I don't think I really *need*
background compilation. Whidbey does an admirable job warning me of the
errors I make most frequently and I simply do not consider the compilation
time significant in most circumstances.
But much more important, perhaps you missed my last paragraph, in which I
presented a hope that the two camps might come somewhat closer together,
rather than holding such deep investment in a single way of doing things.
I often see this in people who have never known anything other than a
single programming language, and therefore believe that the way it does
things is the only right way to do them. These are usually young
programmers, in the early stages of their careers, to whom exposure to
other ways of doing things hasn't yet given a wider perspective. I
wouldn't think you could get to be an MVP without being a rather
experienced developer, and unless C++ is the only language you've ever
known before C#, and unless you have had no experience in any other
development environments, I'd expect you to have a balanced viewpoint as
well. Do I misunderstand?


I saw it but I didn't have any comments.

As for my experiance, I certainly am not the most experianced person around
here and will not claim to be, although I am not alone in my opinion about
E&C by any means. Believe it or not, I've spent most of my career using VB,
I even used E&C for a year or so. But I eventually started looking at my
code and the code the greater community was creating and publishing, and it
became pretty clear that E&C had a noticable taint. People wrote for and in
E&C, instead of using it as a tool to fix the occasional minor mistake. I
even began to notice tutorials that taught people to write within E&C
itself.
E&C is generally used as a crutch first and as a tool second. That isn't
going to change.

I am forced to wonder what mollifying the masses really cost. E&C support
required modifications to the IDE, the debugger,the runtime, and probably to
the compilers. So, the CLR folks were forced to put in the piping to support
E&C, costing what? What was dropped from or never considered for the
debugger to find the time to implement its piece of E&C? The VB team put
together E&C support and delievered a product that I don't think evolved as
significantly as C# and C++/CLI did, what was left out to support E&C? The
C# team managed to wedge it in, but again, at what cost? All they've said so
far is no announced feature was dropped. However, there are still edges that
needed polishing, right down to features I use every ten minutes, like
refactorings. As best as I can tell, the end user is stuck with some runtime
code that exists to support E&C, even though they will never have a reason
to use it.

And all of this was done to provide a feature that basically either allows
people to write bad code quickly or to use the feature once in a while. Was
it worth it? Or was it added because VB6 developers were to stuck on the
idea to let it go?
Nov 21 '05 #9
> I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code, It seems clear to me that E & C would be useful in a large project where the
compile / link time can be minutes or longer. Most things can be used badly
but does that mean we shouldn't have them if the pros outweigh the cons?
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind. While we're at it let's cut
the debugger out as well. Heck let's go the whole hog and get rid of Dev
Studio, going back to trusty old notepad and cmd.

Regards
Lee

Jon
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Tom Dacon <td****@community.nospam> wrote:
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should have sprinkled some smileys around my comments to put across the notion that I was aiming at irreverence rather than vitriol. In any case, I don't agree with your responses, although I respect your right to hold them.

As to edit-and-continue, surely you do deep-path inspection of your
code during testing, don't you? Isn't it a pain when you're deep in a
debugging session, hit a show-stopper, and have to exit the session,
fix the bug, and then reconstruct the whole testing scenario back
down to that point again before you can continue? Sometimes you can
save the situation right there and proceed. Saves a lot of time. Of
course it doesn't always work that way, but every once in a while you
gain from its presence. I missed hearing that the C# team has decided
to do it - thanks for correcting me - but I'm delighted to hear it.
Try it some time, when you get it in a version of VS.Net that
supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.

I'll probably find it useful when viewing a UI, so that I can change a
few behavioural things to see what feels best as a user, but as a way
of debugging I think it leaves a lot to be desired.

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

Nov 21 '05 #10

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Tom Dacon <td****@community.nospam> wrote:
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should have sprinkled some smileys around my comments to put across the notion that I was aiming at irreverence rather than vitriol. In any case, I don't agree with your responses, although I respect your right to hold them.

As to edit-and-continue, surely you do deep-path inspection of your
code during testing, don't you? Isn't it a pain when you're deep in a
debugging session, hit a show-stopper, and have to exit the session,
fix the bug, and then reconstruct the whole testing scenario back
down to that point again before you can continue? Sometimes you can
save the situation right there and proceed. Saves a lot of time. Of
course it doesn't always work that way, but every once in a while you
gain from its presence. I missed hearing that the C# team has decided
to do it - thanks for correcting me - but I'm delighted to hear it.
Try it some time, when you get it in a version of VS.Net that
supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.


there you go again jon - your position here is just what you argue against -
the arrogant attitude.

your "my way is right - all others are wrong" is getting old.

the more energy you spend on judging, the less you have for love!

regards
roy fine
Nov 21 '05 #11
Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code, It seems clear to me that E & C would be useful in a large project where the
compile / link time can be minutes or longer.


I would suggest that unit tests would be a more useful thing there.
(With a modern machine, it has to be a *very* big project for the C#
compiler to literally take minutes, btw. If your project is that large
and you can't test for bugs in a modular fashion, you've got bigger
problems than E&C.)
Most things can be used badly but does that mean we shouldn't have
them if the pros outweigh the cons?
If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind.
They usually don't lead to sloppy code though - that's the difference.
While we're at it let's cut the debugger out as well. Heck let's go
the whole hog and get rid of Dev Studio, going back to trusty old
notepad and cmd.


Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? Do you think it's impossible for one
feature to do more harm than good without all features having that
trait?

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #12
> I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code, It seems clear to me that E & C would be useful in a large project where the
compile / link time can be minutes or longer. Most things can be used badly
but does that mean we shouldn't have them if the pros outweigh the cons?
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind. While we're at it let's cut
the debugger out as well. Heck let's go the whole hog and get rid of Dev
Studio, going back to trusty old notepad and cmd.

Regards
Lee

Jon
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Tom Dacon <td****@community.nospam> wrote:
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should have sprinkled some smileys around my comments to put across the notion that I was aiming at irreverence rather than vitriol. In any case, I don't agree with your responses, although I respect your right to hold them.

As to edit-and-continue, surely you do deep-path inspection of your
code during testing, don't you? Isn't it a pain when you're deep in a
debugging session, hit a show-stopper, and have to exit the session,
fix the bug, and then reconstruct the whole testing scenario back
down to that point again before you can continue? Sometimes you can
save the situation right there and proceed. Saves a lot of time. Of
course it doesn't always work that way, but every once in a while you
gain from its presence. I missed hearing that the C# team has decided
to do it - thanks for correcting me - but I'm delighted to hear it.
Try it some time, when you get it in a version of VS.Net that
supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.

I'll probably find it useful when viewing a UI, so that I can change a
few behavioural things to see what feels best as a user, but as a way
of debugging I think it leaves a lot to be desired.

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

Nov 21 '05 #13
Roy Fine <rl****@twt.obfuscate.net> wrote:
I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.


there you go again jon - your position here is just what you argue against -
the arrogant attitude.

your "my way is right - all others are wrong" is getting old.


Do you disagree that using E&C all the time instead of spending time up
front is a bad way of coding, or are you disagreeing with the presence
of E&C leading to bad habits?

If it's the first, then I'm quite happy to argue that with you. I *do*
think that writing code as it runs is a bad way of coding which will
lead to numerous bugs.

If it's the second, then I can't see where you're getting the idea that
I'm putting forward an attitude of "my way is right - all others are
wrong": we're disagreeing about whether a feature is habit-forming or
not, not whether or not that habit is wrong as habit.

I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #14
I am totally with John and can't understand why Pro-E&C people think we
haven't used it. I have used it enough to know that it leads to really bad
habits and people are using it for things that Unit Tests are a much better
solution for. My arguments are summarized here:
Unit tests, Refactoring not Edit and Continue
http://samgentile.com/blog/archive/2.../19/12240.aspx

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.) Amen
--
Sam Gentile
Microsoft MVP - .NET/C#
INETA Speaker
CLR Blog: http://samgentile.com/blog
..NET Portal and Slides http://samgentile.com/

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
> I have used it, and I believe it leads to bad habits - it leads to only
> thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where
the
compile / link time can be minutes or longer.


I would suggest that unit tests would be a more useful thing there.
(With a modern machine, it has to be a *very* big project for the C#
compiler to literally take minutes, btw. If your project is that large
and you can't test for bugs in a modular fashion, you've got bigger
problems than E&C.)
Most things can be used badly but does that mean we shouldn't have
them if the pros outweigh the cons?


If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind.


They usually don't lead to sloppy code though - that's the difference.
While we're at it let's cut the debugger out as well. Heck let's go
the whole hog and get rid of Dev Studio, going back to trusty old
notepad and cmd.


Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? Do you think it's impossible for one
feature to do more harm than good without all features having that
trait?

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

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

Nov 21 '05 #15

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Tom Dacon <td****@community.nospam> wrote:
Goodness - ruffled a C# feather, didn't I? I certainly didn't intend any
offense (I was, after all, speaking to the OP, not to you), but I'm a
plain-spoken man and I calls 'em as I sees 'em, although perhaps I should have sprinkled some smileys around my comments to put across the notion that I was aiming at irreverence rather than vitriol. In any case, I don't agree with your responses, although I respect your right to hold them.

As to edit-and-continue, surely you do deep-path inspection of your
code during testing, don't you? Isn't it a pain when you're deep in a
debugging session, hit a show-stopper, and have to exit the session,
fix the bug, and then reconstruct the whole testing scenario back
down to that point again before you can continue? Sometimes you can
save the situation right there and proceed. Saves a lot of time. Of
course it doesn't always work that way, but every once in a while you
gain from its presence. I missed hearing that the C# team has decided
to do it - thanks for correcting me - but I'm delighted to hear it.
Try it some time, when you get it in a version of VS.Net that
supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.


there you go again jon - your position here is just what you argue against -
the arrogant attitude.

your "my way is right - all others are wrong" is getting old.

the more energy you spend on judging, the less you have for love!

regards
roy fine
Nov 21 '05 #16
Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code, It seems clear to me that E & C would be useful in a large project where the
compile / link time can be minutes or longer.


I would suggest that unit tests would be a more useful thing there.
(With a modern machine, it has to be a *very* big project for the C#
compiler to literally take minutes, btw. If your project is that large
and you can't test for bugs in a modular fashion, you've got bigger
problems than E&C.)
Most things can be used badly but does that mean we shouldn't have
them if the pros outweigh the cons?
If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind.
They usually don't lead to sloppy code though - that's the difference.
While we're at it let's cut the debugger out as well. Heck let's go
the whole hog and get rid of Dev Studio, going back to trusty old
notepad and cmd.


Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? Do you think it's impossible for one
feature to do more harm than good without all features having that
trait?

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #17
> If the pros outweighed the cons, then yes. In this case, I don't
believe that's true. I disagree but there you go. Each to their own :-)
Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? I haven't noticed, I always like your postings (you do a great job) but I
will say that there seems to be a trend with some programmers who I liken to
the flagellants of medieval times. They seem to think that the amount of
pain they inflict on themselves is inversely proportional to the chances of
catching the black death (bad coding habit).
(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.) Some say that you should step through every bit of code your write to make
sure its doing what you intended. I subscribe to this approach.

Regards
Lee

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
I have used it, and I believe it leads to bad habits - it leads to only thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where the compile / link time can be minutes or longer.


I would suggest that unit tests would be a more useful thing there.
(With a modern machine, it has to be a *very* big project for the C#
compiler to literally take minutes, btw. If your project is that large
and you can't test for bugs in a modular fashion, you've got bigger
problems than E&C.)
Most things can be used badly but does that mean we shouldn't have
them if the pros outweigh the cons?


If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.
Perhaps we shouldn't have intellisense and auto-complete lists since they could be construed as leading to a sloppy mind.


They usually don't lead to sloppy code though - that's the difference.
While we're at it let's cut the debugger out as well. Heck let's go
the whole hog and get rid of Dev Studio, going back to trusty old
notepad and cmd.


Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? Do you think it's impossible for one
feature to do more harm than good without all features having that
trait?

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

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

Nov 21 '05 #18
Roy Fine <rl****@twt.obfuscate.net> wrote:
I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.


there you go again jon - your position here is just what you argue against -
the arrogant attitude.

your "my way is right - all others are wrong" is getting old.


Do you disagree that using E&C all the time instead of spending time up
front is a bad way of coding, or are you disagreeing with the presence
of E&C leading to bad habits?

If it's the first, then I'm quite happy to argue that with you. I *do*
think that writing code as it runs is a bad way of coding which will
lead to numerous bugs.

If it's the second, then I can't see where you're getting the idea that
I'm putting forward an attitude of "my way is right - all others are
wrong": we're disagreeing about whether a feature is habit-forming or
not, not whether or not that habit is wrong as habit.

I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #19
I am totally with John and can't understand why Pro-E&C people think we
haven't used it. I have used it enough to know that it leads to really bad
habits and people are using it for things that Unit Tests are a much better
solution for. My arguments are summarized here:
Unit tests, Refactoring not Edit and Continue
http://samgentile.com/blog/archive/2.../19/12240.aspx

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.) Amen
--
Sam Gentile
Microsoft MVP - .NET/C#
INETA Speaker
CLR Blog: http://samgentile.com/blog
..NET Portal and Slides http://samgentile.com/

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
> I have used it, and I believe it leads to bad habits - it leads to only
> thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where
the
compile / link time can be minutes or longer.


I would suggest that unit tests would be a more useful thing there.
(With a modern machine, it has to be a *very* big project for the C#
compiler to literally take minutes, btw. If your project is that large
and you can't test for bugs in a modular fashion, you've got bigger
problems than E&C.)
Most things can be used badly but does that mean we shouldn't have
them if the pros outweigh the cons?


If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind.


They usually don't lead to sloppy code though - that's the difference.
While we're at it let's cut the debugger out as well. Heck let's go
the whole hog and get rid of Dev Studio, going back to trusty old
notepad and cmd.


Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? Do you think it's impossible for one
feature to do more harm than good without all features having that
trait?

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

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

Nov 21 '05 #20
Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.

I disagree but there you go. Each to their own :-)


Absolutely. I'm quite happy to agree to disagree on this one.
Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out?

I haven't noticed, I always like your postings (you do a great job) but I
will say that there seems to be a trend with some programmers who I liken to
the flagellants of medieval times. They seem to think that the amount of
pain they inflict on themselves is inversely proportional to the chances of
catching the black death (bad coding habit).


The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity.

Before Eclipse came out, I used to write my Java servlet code in a
decent text editor (*not* Notepad) and debug it code just using
logging. For the most part, that was absolutely fine - and I was as
productive as my colleagues who used IDEs. Eclipse changed things by
being an IDE which made the actual coding more productive, but there
was never any sense of deliberately restricting myself.
(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

Some say that you should step through every bit of code your write to make
sure its doing what you intended. I subscribe to this approach.


I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc. (There are also
*always* problems with debuggers showing incorrect data etc. A
colleague had exactly that this morning - the debugger was showing an
ArrayList with 4 items but with a Count property of 1.)

Personally I think code should be *so* simple that it's blatantly
obvious what each bit does. The debugger only gives an "up close" view,
which should usually be obvious. It's the sense of how things fit
together on a larger scale which I usually need to work on, and the
debugger rarely helps there. I mostly find the debugger helpful for
times when an API doesn't work in the way I expect it to. Every so
often that's not true, but usually when I notice there's a bug, just
thinking about why it's occurred gets me to the problematic code faster
than firing up the debugger.

Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #21
> If the pros outweighed the cons, then yes. In this case, I don't
believe that's true. I disagree but there you go. Each to their own :-)
Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? I haven't noticed, I always like your postings (you do a great job) but I
will say that there seems to be a trend with some programmers who I liken to
the flagellants of medieval times. They seem to think that the amount of
pain they inflict on themselves is inversely proportional to the chances of
catching the black death (bad coding habit).
(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.) Some say that you should step through every bit of code your write to make
sure its doing what you intended. I subscribe to this approach.

Regards
Lee

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
I have used it, and I believe it leads to bad habits - it leads to only thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where the compile / link time can be minutes or longer.


I would suggest that unit tests would be a more useful thing there.
(With a modern machine, it has to be a *very* big project for the C#
compiler to literally take minutes, btw. If your project is that large
and you can't test for bugs in a modular fashion, you've got bigger
problems than E&C.)
Most things can be used badly but does that mean we shouldn't have
them if the pros outweigh the cons?


If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.
Perhaps we shouldn't have intellisense and auto-complete lists since they could be construed as leading to a sloppy mind.


They usually don't lead to sloppy code though - that's the difference.
While we're at it let's cut the debugger out as well. Heck let's go
the whole hog and get rid of Dev Studio, going back to trusty old
notepad and cmd.


Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out? Do you think it's impossible for one
feature to do more harm than good without all features having that
trait?

(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

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

Nov 21 '05 #22
Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.

I disagree but there you go. Each to their own :-)


Absolutely. I'm quite happy to agree to disagree on this one.
Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out?

I haven't noticed, I always like your postings (you do a great job) but I
will say that there seems to be a trend with some programmers who I liken to
the flagellants of medieval times. They seem to think that the amount of
pain they inflict on themselves is inversely proportional to the chances of
catching the black death (bad coding habit).


The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity.

Before Eclipse came out, I used to write my Java servlet code in a
decent text editor (*not* Notepad) and debug it code just using
logging. For the most part, that was absolutely fine - and I was as
productive as my colleagues who used IDEs. Eclipse changed things by
being an IDE which made the actual coding more productive, but there
was never any sense of deliberately restricting myself.
(Having said that, I believe a good developer shouldn't usually need to
use the debugger very often.)

Some say that you should step through every bit of code your write to make
sure its doing what you intended. I subscribe to this approach.


I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc. (There are also
*always* problems with debuggers showing incorrect data etc. A
colleague had exactly that this morning - the debugger was showing an
ArrayList with 4 items but with a Count property of 1.)

Personally I think code should be *so* simple that it's blatantly
obvious what each bit does. The debugger only gives an "up close" view,
which should usually be obvious. It's the sense of how things fit
together on a larger scale which I usually need to work on, and the
debugger rarely helps there. I mostly find the debugger helpful for
times when an API doesn't work in the way I expect it to. Every so
often that's not true, but usually when I notice there's a bug, just
thinking about why it's occurred gets me to the problematic code faster
than firing up the debugger.

Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #23
Sam,

"Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
I am totally with John and can't understand why Pro-E&C
people think we haven't used it.
Maybe you and some of the others used it. In the German C# community there
are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.
I have used it enough to know that it leads to really bad
habits
Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.
and people are using it for things that Unit Tests are a much better
solution for.
I prefer a combination of both: Unit testing and E&C.
My arguments are summarized here:
Unit tests, Refactoring not Edit and Continue
http://samgentile.com/blog/archive/2.../19/12240.aspx


Does it really matter if you are editing your code in debug mode or in plain
design mode? I doubt that this has an impact on the quality of the code,
and I don't see big differences except that E&C makes restarting execution
with certain data easier and faster than without E&C.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #24
"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only thinking about the quality of code when you're running the code,
instead of beforehand.
there you go again jon - your position here is just what you argue against - the arrogant attitude.

your "my way is right - all others are wrong" is getting old.


Do you disagree that using E&C all the time instead of spending time up
front is a bad way of coding, or are you disagreeing with the presence
of E&C leading to bad habits?

If it's the first, then I'm quite happy to argue that with you. I *do*
think that writing code as it runs is a bad way of coding which will
lead to numerous bugs.


Why? What's the exact difference you experience? There is no timeout in
debug mode that forces you to edit as quick as possible. You can sit down
and rethink/implement logic without time pressure even in debug mode.
I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.


This strongly depends on the developer.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #25
Hi Jon,

I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.


That's an excellent summary of the key topic... probably the best summary
here.

I'm not "aligned" with any one, nor do I believe that all opponents of E&C
are immature developers who've only ever used C++. Your concern is a valid
one.

I do NOT believe that starting the debugger, and then writing code, is a
good idea. That's a hair-brained idea. On the other hand, I haven't met
anyone who does that. Just how many advocates of "write in the debugger"
have you met at conferences or SIGs or in your dev teams? Could it be that
the concern about coding in the debugger is an overreaction to the nutty
ideas of a tiny minority?

My contribution to this discussion:

First off, E&C is a feature of the environment, like the object browser,
server explorer, and that nifty little ability to leave TODO notes. That is
my starting context. Just one feature among many.

In my opinion, E&C is a valuable addition to the environment, and was worth
the efforts of the developers to create it. When I was writing in VB, I
used it rarely. (I used the debugger on occasion, of course, but E&C just
wasn't needed most of the time). That said, the few times over the years
when it really came in handy, it probably saved me as much time as any other
single feature (like the object browser, or server explorer).

These days, I spend my time in C#, and have grown accostomed to not having
it. I don't miss it terribly, but every now and then, when debugging a unit
test case, it would be nice to be able to fix the code on the spot, verify
that the test runs, and go on. Yes, that invalidates the test (other tests
have already passed, tests which may fail now) but I am a pretty good
developer... and I can tell when a change runs a potential risk of breaking
something. When I make a change like that, I would stop the session, make
the change, and rerun the unit test suite.

If the concept of "fix and continue" worries you, then I'd like you to
consider one aspect of agile development. You seem like you are a supporter
of agile but I cannot be certain, of course. Forgive me if I "over explain"
for those folks who are not well versed in agile practices.

In agile development, you don't try to _know_ everything... you lower the
cost of learning and changing the code. Unit tests are a way of insuring
that refactoring and new requirements won't introduce bugs. Their existence
lowers the cost (and the fear) associated with changing the code.
Literally: "change it all you want," as long as the number of tests passed
keeps increasing and the tests are as rational as you can make them.

However, I run my unit tests at least a half-dozen times during the day, and
frequently far more. If I make a change in E&C and I don't catch it this
time, I will catch it next time. I'm not concerned by that. One more
point: One of the key concepts of Test Driven Development is (a) write the
test and then (b) write ONLY enough code so that you can pass the test. If
E&C allows you to write only enough code to pass the test, then it is
supporting TDD.

Can E&C be misused? Yes, and we should warn folks about that. Tell them
that E&C is not a healthy way to originate code. However, just like I
believe Singletons can be misused, but that folks should only be warned, I
believe that E&C can be misused, and that a warning is all that should be
issued.

I'm only inclined to "remove" or "oppose" a feature of a language or an IDE
if it creates code that cannot be encountered except in the debugger, or it
fosters and encourages poor _structure_. In other words, nearly never.

C++ had a 'goto' statement. All of the coding guidelines I've seen said
"don't use it." However, I did perform a code review (around 1990) when a
very seasoned developer made a case for the 'goto' in his code and it
remained in the production code. It can happen that statements or practices
"considered harmful" are still useful.

I fall on the side of education, not restriction.

--- Nick
Nov 21 '05 #26
Sam,

"Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
I am totally with John and can't understand why Pro-E&C
people think we haven't used it.
Maybe you and some of the others used it. In the German C# community there
are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.
I have used it enough to know that it leads to really bad
habits
Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.
and people are using it for things that Unit Tests are a much better
solution for.
I prefer a combination of both: Unit testing and E&C.
My arguments are summarized here:
Unit tests, Refactoring not Edit and Continue
http://samgentile.com/blog/archive/2.../19/12240.aspx


Does it really matter if you are editing your code in debug mode or in plain
design mode? I doubt that this has an impact on the quality of the code,
and I don't see big differences except that E&C makes restarting execution
with certain data easier and faster than without E&C.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #27
"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:
I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only thinking about the quality of code when you're running the code,
instead of beforehand.
there you go again jon - your position here is just what you argue against - the arrogant attitude.

your "my way is right - all others are wrong" is getting old.


Do you disagree that using E&C all the time instead of spending time up
front is a bad way of coding, or are you disagreeing with the presence
of E&C leading to bad habits?

If it's the first, then I'm quite happy to argue that with you. I *do*
think that writing code as it runs is a bad way of coding which will
lead to numerous bugs.


Why? What's the exact difference you experience? There is no timeout in
debug mode that forces you to edit as quick as possible. You can sit down
and rethink/implement logic without time pressure even in debug mode.
I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.


This strongly depends on the developer.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #28
Hi Jon,

I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.


That's an excellent summary of the key topic... probably the best summary
here.

I'm not "aligned" with any one, nor do I believe that all opponents of E&C
are immature developers who've only ever used C++. Your concern is a valid
one.

I do NOT believe that starting the debugger, and then writing code, is a
good idea. That's a hair-brained idea. On the other hand, I haven't met
anyone who does that. Just how many advocates of "write in the debugger"
have you met at conferences or SIGs or in your dev teams? Could it be that
the concern about coding in the debugger is an overreaction to the nutty
ideas of a tiny minority?

My contribution to this discussion:

First off, E&C is a feature of the environment, like the object browser,
server explorer, and that nifty little ability to leave TODO notes. That is
my starting context. Just one feature among many.

In my opinion, E&C is a valuable addition to the environment, and was worth
the efforts of the developers to create it. When I was writing in VB, I
used it rarely. (I used the debugger on occasion, of course, but E&C just
wasn't needed most of the time). That said, the few times over the years
when it really came in handy, it probably saved me as much time as any other
single feature (like the object browser, or server explorer).

These days, I spend my time in C#, and have grown accostomed to not having
it. I don't miss it terribly, but every now and then, when debugging a unit
test case, it would be nice to be able to fix the code on the spot, verify
that the test runs, and go on. Yes, that invalidates the test (other tests
have already passed, tests which may fail now) but I am a pretty good
developer... and I can tell when a change runs a potential risk of breaking
something. When I make a change like that, I would stop the session, make
the change, and rerun the unit test suite.

If the concept of "fix and continue" worries you, then I'd like you to
consider one aspect of agile development. You seem like you are a supporter
of agile but I cannot be certain, of course. Forgive me if I "over explain"
for those folks who are not well versed in agile practices.

In agile development, you don't try to _know_ everything... you lower the
cost of learning and changing the code. Unit tests are a way of insuring
that refactoring and new requirements won't introduce bugs. Their existence
lowers the cost (and the fear) associated with changing the code.
Literally: "change it all you want," as long as the number of tests passed
keeps increasing and the tests are as rational as you can make them.

However, I run my unit tests at least a half-dozen times during the day, and
frequently far more. If I make a change in E&C and I don't catch it this
time, I will catch it next time. I'm not concerned by that. One more
point: One of the key concepts of Test Driven Development is (a) write the
test and then (b) write ONLY enough code so that you can pass the test. If
E&C allows you to write only enough code to pass the test, then it is
supporting TDD.

Can E&C be misused? Yes, and we should warn folks about that. Tell them
that E&C is not a healthy way to originate code. However, just like I
believe Singletons can be misused, but that folks should only be warned, I
believe that E&C can be misused, and that a warning is all that should be
issued.

I'm only inclined to "remove" or "oppose" a feature of a language or an IDE
if it creates code that cannot be encountered except in the debugger, or it
fosters and encourages poor _structure_. In other words, nearly never.

C++ had a 'goto' statement. All of the coding guidelines I've seen said
"don't use it." However, I did perform a code review (around 1990) when a
very seasoned developer made a case for the 'goto' in his code and it
remained in the production code. It can happen that statements or practices
"considered harmful" are still useful.

I fall on the side of education, not restriction.

--- Nick
Nov 21 '05 #29
> The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity. Which fits nicely with my earlier point that with anything you can pervert
its use to the detriment of the greater good. Does that mean we shouldn't
have a debugger? I hope not, clearly someone who fires up the debugger with
an empty main entry point using E & C to write there code on the fly is in
need of help.
and I was as productive as my colleagues who used IDEs. How did you measure this?
I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc. You can't even do this with unit tests either (practically speaking). I am
also a firm believer in unit testing; when dealing with a non-trivial body
of code it's an absolute must have. I also still believe in stepping through
new code making sure that it's working in accordance with your expectations.
Personally I think code should be *so* simple that it's blatantly
obvious what each bit does. Sounds good to me :-)
Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. Yep.
I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing... I'm sure you'll be able to cherry pick your *perfect* job :-)

Regards
Lee

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.

I disagree but there you go. Each to their own :-)


Absolutely. I'm quite happy to agree to disagree on this one.
Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out?

I haven't noticed, I always like your postings (you do a great job) but I
will say that there seems to be a trend with some programmers who I liken to the flagellants of medieval times. They seem to think that the amount of
pain they inflict on themselves is inversely proportional to the chances of catching the black death (bad coding habit).


The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity.

Before Eclipse came out, I used to write my Java servlet code in a
decent text editor (*not* Notepad) and debug it code just using
logging. For the most part, that was absolutely fine - and I was as
productive as my colleagues who used IDEs. Eclipse changed things by
being an IDE which made the actual coding more productive, but there
was never any sense of deliberately restricting myself.
(Having said that, I believe a good developer shouldn't usually need to use the debugger very often.)

Some say that you should step through every bit of code your write to make sure its doing what you intended. I subscribe to this approach.


I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc. (There are also
*always* problems with debuggers showing incorrect data etc. A
colleague had exactly that this morning - the debugger was showing an
ArrayList with 4 items but with a Count property of 1.)

Personally I think code should be *so* simple that it's blatantly
obvious what each bit does. The debugger only gives an "up close" view,
which should usually be obvious. It's the sense of how things fit
together on a larger scale which I usually need to work on, and the
debugger rarely helps there. I mostly find the debugger helpful for
times when an API doesn't work in the way I expect it to. Every so
often that's not true, but usually when I notice there's a bug, just
thinking about why it's occurred gets me to the problematic code faster
than firing up the debugger.

Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

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

Nov 21 '05 #30
Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:
Do you disagree that using E&C all the time instead of spending time up
front is a bad way of coding, or are you disagreeing with the presence
of E&C leading to bad habits?

If it's the first, then I'm quite happy to argue that with you. I *do*
think that writing code as it runs is a bad way of coding which will
lead to numerous bugs.


Why? What's the exact difference you experience? There is no timeout in
debug mode that forces you to edit as quick as possible. You can sit down
and rethink/implement logic without time pressure even in debug mode.


No, but once you've got something which works for the particular bug
you've run across, there's not (IMO) the same impetus to mentally check
through all the other cases which might happen. If you're relying on
the debugger to show you what code does in one case, you're probably
not thinking about all the other cases. (Generic "you" there, btw - not
you in particular.)
I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.


This strongly depends on the developer.


Sure - but I think it's worth strong developers sacrificing a bit of
ease for the sake of not encouraging bad habits in weaker or less
experienced developers. (As Daniel mentioned, there's also the issue of
what else has been missed out due to the effort of including E&C.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #31
> The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity. Which fits nicely with my earlier point that with anything you can pervert
its use to the detriment of the greater good. Does that mean we shouldn't
have a debugger? I hope not, clearly someone who fires up the debugger with
an empty main entry point using E & C to write there code on the fly is in
need of help.
and I was as productive as my colleagues who used IDEs. How did you measure this?
I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc. You can't even do this with unit tests either (practically speaking). I am
also a firm believer in unit testing; when dealing with a non-trivial body
of code it's an absolute must have. I also still believe in stepping through
new code making sure that it's working in accordance with your expectations.
Personally I think code should be *so* simple that it's blatantly
obvious what each bit does. Sounds good to me :-)
Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. Yep.
I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing... I'm sure you'll be able to cherry pick your *perfect* job :-)

Regards
Lee

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
If the pros outweighed the cons, then yes. In this case, I don't
believe that's true.

I disagree but there you go. Each to their own :-)


Absolutely. I'm quite happy to agree to disagree on this one.
Why is it that whenever I have this discussion, I'm painted as someone
who wants to throw everything out?

I haven't noticed, I always like your postings (you do a great job) but I
will say that there seems to be a trend with some programmers who I liken to the flagellants of medieval times. They seem to think that the amount of
pain they inflict on themselves is inversely proportional to the chances of catching the black death (bad coding habit).


The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity.

Before Eclipse came out, I used to write my Java servlet code in a
decent text editor (*not* Notepad) and debug it code just using
logging. For the most part, that was absolutely fine - and I was as
productive as my colleagues who used IDEs. Eclipse changed things by
being an IDE which made the actual coding more productive, but there
was never any sense of deliberately restricting myself.
(Having said that, I believe a good developer shouldn't usually need to use the debugger very often.)

Some say that you should step through every bit of code your write to make sure its doing what you intended. I subscribe to this approach.


I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc. (There are also
*always* problems with debuggers showing incorrect data etc. A
colleague had exactly that this morning - the debugger was showing an
ArrayList with 4 items but with a Count property of 1.)

Personally I think code should be *so* simple that it's blatantly
obvious what each bit does. The debugger only gives an "up close" view,
which should usually be obvious. It's the sense of how things fit
together on a larger scale which I usually need to work on, and the
debugger rarely helps there. I mostly find the debugger helpful for
times when an API doesn't work in the way I expect it to. Every so
often that's not true, but usually when I notice there's a bug, just
thinking about why it's occurred gets me to the problematic code faster
than firing up the debugger.

Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to. I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

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

Nov 21 '05 #32
Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:
Do you disagree that using E&C all the time instead of spending time up
front is a bad way of coding, or are you disagreeing with the presence
of E&C leading to bad habits?

If it's the first, then I'm quite happy to argue that with you. I *do*
think that writing code as it runs is a bad way of coding which will
lead to numerous bugs.


Why? What's the exact difference you experience? There is no timeout in
debug mode that forces you to edit as quick as possible. You can sit down
and rethink/implement logic without time pressure even in debug mode.


No, but once you've got something which works for the particular bug
you've run across, there's not (IMO) the same impetus to mentally check
through all the other cases which might happen. If you're relying on
the debugger to show you what code does in one case, you're probably
not thinking about all the other cases. (Generic "you" there, btw - not
you in particular.)
I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.


This strongly depends on the developer.


Sure - but I think it's worth strong developers sacrificing a bit of
ease for the sake of not encouraging bad habits in weaker or less
experienced developers. (As Daniel mentioned, there's also the issue of
what else has been missed out due to the effort of including E&C.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #33
Nick Malik <ni*******@hotmail.nospam.com> wrote:
I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.
That's an excellent summary of the key topic... probably the best summary
here.

I'm not "aligned" with any one, nor do I believe that all opponents of E&C
are immature developers who've only ever used C++. Your concern is a valid
one.

I do NOT believe that starting the debugger, and then writing code, is a
good idea. That's a hair-brained idea. On the other hand, I haven't met
anyone who does that. Just how many advocates of "write in the debugger"
have you met at conferences or SIGs or in your dev teams? Could it be that
the concern about coding in the debugger is an overreaction to the nutty
ideas of a tiny minority?


I happen to usually work with experienced developers. (In the company
I'm in now, I'm the most junior by over 10 years, and have been for
most of the time.)

However, I've seen plenty of code which suggests that people have been
writing code in the "try rather than think" mode.

<snip excellent discussion>
Can E&C be misused? Yes, and we should warn folks about that. Tell them
that E&C is not a healthy way to originate code. However, just like I
believe Singletons can be misused, but that folks should only be warned, I
believe that E&C can be misused, and that a warning is all that should be
issued.


I think we just disagree about how often it'll be misused rather than
how often it'll be used correctly. Virtually everything else, we agree
about (although unit tests should generally build and run quickly
enough that E&C shouldn't cause much of a difference, IMO).

Gotta go now, but thanks for the non-patronising discussion. I think
this issue is one which leads to more assumptions about people than
almost any other (in development) :(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #34
Nick Malik <ni*******@hotmail.nospam.com> wrote:
I'm just expressing an opinion: that the presence of E&C leads to
developers over-using it, which naturally leads to bad code due to less
time being spent on thinking about what the code should look like
before trying to run it.
That's an excellent summary of the key topic... probably the best summary
here.

I'm not "aligned" with any one, nor do I believe that all opponents of E&C
are immature developers who've only ever used C++. Your concern is a valid
one.

I do NOT believe that starting the debugger, and then writing code, is a
good idea. That's a hair-brained idea. On the other hand, I haven't met
anyone who does that. Just how many advocates of "write in the debugger"
have you met at conferences or SIGs or in your dev teams? Could it be that
the concern about coding in the debugger is an overreaction to the nutty
ideas of a tiny minority?


I happen to usually work with experienced developers. (In the company
I'm in now, I'm the most junior by over 10 years, and have been for
most of the time.)

However, I've seen plenty of code which suggests that people have been
writing code in the "try rather than think" mode.

<snip excellent discussion>
Can E&C be misused? Yes, and we should warn folks about that. Tell them
that E&C is not a healthy way to originate code. However, just like I
believe Singletons can be misused, but that folks should only be warned, I
believe that E&C can be misused, and that a warning is all that should be
issued.


I think we just disagree about how often it'll be misused rather than
how often it'll be used correctly. Virtually everything else, we agree
about (although unit tests should generally build and run quickly
enough that E&C shouldn't cause much of a difference, IMO).

Gotta go now, but thanks for the non-patronising discussion. I think
this issue is one which leads to more assumptions about people than
almost any other (in development) :(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #35
Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity.
Which fits nicely with my earlier point that with anything you can pervert
its use to the detriment of the greater good. Does that mean we shouldn't
have a debugger? I hope not, clearly someone who fires up the debugger with
an empty main entry point using E & C to write there code on the fly is in
need of help.


I answered that earlier - in some cases (like a debugger) the pros
outweigh the cons. For E&C, I believe the cons outweigh the pros.
and I was as productive as my colleagues who used IDEs.

How did you measure this?


Code written, bugs fixed, bugs not created in the first place.
Informally, of course.
I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc.

You can't even do this with unit tests either (practically speaking). I am
also a firm believer in unit testing; when dealing with a non-trivial body
of code it's an absolute must have. I also still believe in stepping through
new code making sure that it's working in accordance with your expectations.


I can't say I've ever found it useful. Not that I'm trying to stop you,
of course :)
Personally I think code should be *so* simple that it's blatantly
obvious what each bit does.

Sounds good to me :-)
Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to.

Yep.
I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

I'm sure you'll be able to cherry pick your *perfect* job :-)


That would be lovely, but the market isn't quite that nice :)

Still, I've got an online C# test to do in a few minutes, so that
should be fun...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #36
Lee Alexander <lee@NoSpamPlease_Digita.com> wrote:
The opposite is also true though - people tend to assume that using the
debugger a lot and starting to run the code as quickly as possible will
boost their productivity.
Which fits nicely with my earlier point that with anything you can pervert
its use to the detriment of the greater good. Does that mean we shouldn't
have a debugger? I hope not, clearly someone who fires up the debugger with
an empty main entry point using E & C to write there code on the fly is in
need of help.


I answered that earlier - in some cases (like a debugger) the pros
outweigh the cons. For E&C, I believe the cons outweigh the pros.
and I was as productive as my colleagues who used IDEs.

How did you measure this?


Code written, bugs fixed, bugs not created in the first place.
Informally, of course.
I believe that gives a false sense of confidence though - because you
can't possibly step through every bit of code with every possible set
of data, with every combination of threading etc.

You can't even do this with unit tests either (practically speaking). I am
also a firm believer in unit testing; when dealing with a non-trivial body
of code it's an absolute must have. I also still believe in stepping through
new code making sure that it's working in accordance with your expectations.


I can't say I've ever found it useful. Not that I'm trying to stop you,
of course :)
Personally I think code should be *so* simple that it's blatantly
obvious what each bit does.

Sounds good to me :-)
Being able to have all your code run is a good idea though - and that's
what unit tests are for. They allow you to make sure that all your code
is run *on a regular basis* rather than just the once through with the
debugger. Unit testing is one of those things I've never used as
thoroughly as I'd like to.

Yep.
I'm currently looking for another job, and I
seriously hope that wherever I go embraces unit testing...

I'm sure you'll be able to cherry pick your *perfect* job :-)


That would be lovely, but the market isn't quite that nice :)

Still, I've got an online C# test to do in a few minutes, so that
should be fun...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #37

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eR*************@TK2MSFTNGP10.phx.gbl...
Sam,

"Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
I am totally with John and can't understand why Pro-E&C
people think we haven't used it.
Maybe you and some of the others used it. In the German C# community

there are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.
I have used it enough to know that it leads to really bad
habits


Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.


EXCELLENT POINT ! Best point made in this thread.

roy fine
Nov 21 '05 #38

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eR*************@TK2MSFTNGP10.phx.gbl...
Sam,

"Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
I am totally with John and can't understand why Pro-E&C
people think we haven't used it.
Maybe you and some of the others used it. In the German C# community

there are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.
I have used it enough to know that it leads to really bad
habits


Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.


EXCELLENT POINT ! Best point made in this thread.

roy fine
Nov 21 '05 #39
Nick, thanks for your comments.

I'm not going to dive into the middle of the E&C debate, although my
experience with it has been good, and I don't feel that the quality of my
code has suffered from its use. I think it's a case of knowing when to use
it, and when to back out and restructure the code if I see that it has
design faults or a poor implementation. The only problem I've had with it is
when I made a fix using E&C and then lost it in a crash of the IDE that
prevented me from saving the change. Psychologically, I felt that the fix
had been made, and sometimes have found that I failed to go back into the
source and reinsert the fix after bringing the project back up again. Other
than that occasional and irritating slipup on my part (and I personally take
full credit for the failing, rather than blaming E&C) I think it's a useful
tool, but just a tool like any other in our arsenals.

As to the new stuff in VB.Net for the next go-round, I'm seriously
considering referencing the My namespace in my C# code, just to get access
to some of the coding shortcuts. I'm not 100% sure that this would be a good
idea, it probably isn't, but I'm mulling it over.

On the 'fair and balanced' thing, I've been in this biz a hell of a long
time, and it seems that there's always a need for people to divide
themselves into the Thems and the Us's. In the old days it was the
engineering programmers versus the business programmers: Fortran and Cobol.
In the early days of Windows, it was the Unix programmers versus the Windows
programmers: X Window System versus the Windows API. In the early days of
the Mac, it was Pascal versus C, and of course it will always, it seems, be
Apple versus Microsoft. For a certain time, Sun and Scott McNealy were the
anti-Christ, and everyone else in the Unix world was against them. On
Windows, for a while it was C++ versus VB1-6, and now it's C# versus VB.Net.
Tires me out. I'd like for us to leave this kind of stuff behind us, and
take the opportunity to learn from each other. I've personally programmed
professionally - delivered a commercial product - in twelve or maybe
thirteen distinct programming languages over a long and varied career, and I
believe that I've learned something useful from all of them, and especially
from the experienced programmers I encountered in the process.

And I apologize to anyone who was offended by my gratuituous dig at the
Republicans in my original post. Just beeped out. Sorry. :-)

Best regards,
Tom Dacon
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:LMnfd.425410$mD.405364@attbi_s02...
Hi Tom,

Daniel has participated in some long-ish discussions recently on the
'negative' aspects of Edit-and-continue. If you search the newsgroups on
Google using his name and the term E&C, you will probably stumble across
the
discussion.

Personally, I agree with you that E&C is useful (as you will see... I
engaged Daniel in that aforementioned discussion). I do not suggest
pursuing that discussion in this thread as well.
Goodness - ruffled a C# feather, didn't I?

His remarks were hardly less offensive than yours... don't sweat it.
But much more important, perhaps you missed my last paragraph, in which I
presented a hope that the two camps might come somewhat closer together,
rather than holding such deep investment in a single way of doing things.


Microsoft is more concerned with marketing to the respective groups than
it
is in religious battles. If a language has a feature, it's because the
developers of that language spoke with the users and decided that the
feature was desirable. From what I've seen of the new version, there's a
lot more in common between the two languages this time, although VB has
added some interesting short-cuts aimed at VB6 developers that still
haven't
switched.
I wouldn't think you could get
to be an MVP without being a rather experienced developer, and unless C++

is
the only language you've ever known before C#, and unless you have had no
experience in any other development environments, I'd expect you to have
a
balanced viewpoint as well. Do I misunderstand?


Let's all hope for balance in our viewpoints, and a fair and respectful
consideration of the ideas of others.

A little humor is nice too.
--- Nick

Nov 21 '05 #40
Nick, thanks for your comments.

I'm not going to dive into the middle of the E&C debate, although my
experience with it has been good, and I don't feel that the quality of my
code has suffered from its use. I think it's a case of knowing when to use
it, and when to back out and restructure the code if I see that it has
design faults or a poor implementation. The only problem I've had with it is
when I made a fix using E&C and then lost it in a crash of the IDE that
prevented me from saving the change. Psychologically, I felt that the fix
had been made, and sometimes have found that I failed to go back into the
source and reinsert the fix after bringing the project back up again. Other
than that occasional and irritating slipup on my part (and I personally take
full credit for the failing, rather than blaming E&C) I think it's a useful
tool, but just a tool like any other in our arsenals.

As to the new stuff in VB.Net for the next go-round, I'm seriously
considering referencing the My namespace in my C# code, just to get access
to some of the coding shortcuts. I'm not 100% sure that this would be a good
idea, it probably isn't, but I'm mulling it over.

On the 'fair and balanced' thing, I've been in this biz a hell of a long
time, and it seems that there's always a need for people to divide
themselves into the Thems and the Us's. In the old days it was the
engineering programmers versus the business programmers: Fortran and Cobol.
In the early days of Windows, it was the Unix programmers versus the Windows
programmers: X Window System versus the Windows API. In the early days of
the Mac, it was Pascal versus C, and of course it will always, it seems, be
Apple versus Microsoft. For a certain time, Sun and Scott McNealy were the
anti-Christ, and everyone else in the Unix world was against them. On
Windows, for a while it was C++ versus VB1-6, and now it's C# versus VB.Net.
Tires me out. I'd like for us to leave this kind of stuff behind us, and
take the opportunity to learn from each other. I've personally programmed
professionally - delivered a commercial product - in twelve or maybe
thirteen distinct programming languages over a long and varied career, and I
believe that I've learned something useful from all of them, and especially
from the experienced programmers I encountered in the process.

And I apologize to anyone who was offended by my gratuituous dig at the
Republicans in my original post. Just beeped out. Sorry. :-)

Best regards,
Tom Dacon
"Nick Malik" <ni*******@hotmail.nospam.com> wrote in message
news:LMnfd.425410$mD.405364@attbi_s02...
Hi Tom,

Daniel has participated in some long-ish discussions recently on the
'negative' aspects of Edit-and-continue. If you search the newsgroups on
Google using his name and the term E&C, you will probably stumble across
the
discussion.

Personally, I agree with you that E&C is useful (as you will see... I
engaged Daniel in that aforementioned discussion). I do not suggest
pursuing that discussion in this thread as well.
Goodness - ruffled a C# feather, didn't I?

His remarks were hardly less offensive than yours... don't sweat it.
But much more important, perhaps you missed my last paragraph, in which I
presented a hope that the two camps might come somewhat closer together,
rather than holding such deep investment in a single way of doing things.


Microsoft is more concerned with marketing to the respective groups than
it
is in religious battles. If a language has a feature, it's because the
developers of that language spoke with the users and decided that the
feature was desirable. From what I've seen of the new version, there's a
lot more in common between the two languages this time, although VB has
added some interesting short-cuts aimed at VB6 developers that still
haven't
switched.
I wouldn't think you could get
to be an MVP without being a rather experienced developer, and unless C++

is
the only language you've ever known before C#, and unless you have had no
experience in any other development environments, I'd expect you to have
a
balanced viewpoint as well. Do I misunderstand?


Let's all hope for balance in our viewpoints, and a fair and respectful
consideration of the ideas of others.

A little humor is nice too.
--- Nick

Nov 21 '05 #41
>> Depends on the programmer. Good programmers will write good code with
and
without E&C, but will write code faster with E&C.


EXCELLENT POINT ! Best point made in this thread.

roy fine


Indeed. I couldn't agree more.

Tom

Nov 21 '05 #42
>> Depends on the programmer. Good programmers will write good code with
and
without E&C, but will write code faster with E&C.


EXCELLENT POINT ! Best point made in this thread.

roy fine


Indeed. I couldn't agree more.

Tom

Nov 21 '05 #43
edlin rules
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
"Lee Alexander" <lee@NoSpamPlease_Digita.com> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where
the
compile / link time can be minutes or longer. Most things can be used
badly
but does that mean we shouldn't have them if the pros outweigh the cons?
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind. While we're at it let's
cut
the debugger out as well. Heck let's go the whole hog and get rid of Dev
Studio, going back to trusty old notepad and cmd.

Regards
Lee

Jon
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Tom Dacon <td****@community.nospam> wrote:
> Goodness - ruffled a C# feather, didn't I? I certainly didn't intend
> any
> offense (I was, after all, speaking to the OP, not to you), but I'm a
> plain-spoken man and I calls 'em as I sees 'em, although perhaps I should > have sprinkled some smileys around my comments to put across the notion that > I was aiming at irreverence rather than vitriol. In any case, I don't agree > with your responses, although I respect your right to hold them.
>
> As to edit-and-continue, surely you do deep-path inspection of your
> code during testing, don't you? Isn't it a pain when you're deep in a
> debugging session, hit a show-stopper, and have to exit the session,
> fix the bug, and then reconstruct the whole testing scenario back
> down to that point again before you can continue? Sometimes you can
> save the situation right there and proceed. Saves a lot of time. Of
> course it doesn't always work that way, but every once in a while you
> gain from its presence. I missed hearing that the C# team has decided
> to do it - thanks for correcting me - but I'm delighted to hear it.
> Try it some time, when you get it in a version of VS.Net that
> supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.

I'll probably find it useful when viewing a UI, so that I can change a
few behavioural things to see what feels best as a user, but as a way
of debugging I think it leaves a lot to be desired.

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


Nov 21 '05 #44
edlin rules
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
"Lee Alexander" <lee@NoSpamPlease_Digita.com> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,

It seems clear to me that E & C would be useful in a large project where
the
compile / link time can be minutes or longer. Most things can be used
badly
but does that mean we shouldn't have them if the pros outweigh the cons?
Perhaps we shouldn't have intellisense and auto-complete lists since they
could be construed as leading to a sloppy mind. While we're at it let's
cut
the debugger out as well. Heck let's go the whole hog and get rid of Dev
Studio, going back to trusty old notepad and cmd.

Regards
Lee

Jon
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Tom Dacon <td****@community.nospam> wrote:
> Goodness - ruffled a C# feather, didn't I? I certainly didn't intend
> any
> offense (I was, after all, speaking to the OP, not to you), but I'm a
> plain-spoken man and I calls 'em as I sees 'em, although perhaps I should > have sprinkled some smileys around my comments to put across the notion that > I was aiming at irreverence rather than vitriol. In any case, I don't agree > with your responses, although I respect your right to hold them.
>
> As to edit-and-continue, surely you do deep-path inspection of your
> code during testing, don't you? Isn't it a pain when you're deep in a
> debugging session, hit a show-stopper, and have to exit the session,
> fix the bug, and then reconstruct the whole testing scenario back
> down to that point again before you can continue? Sometimes you can
> save the situation right there and proceed. Saves a lot of time. Of
> course it doesn't always work that way, but every once in a while you
> gain from its presence. I missed hearing that the C# team has decided
> to do it - thanks for correcting me - but I'm delighted to hear it.
> Try it some time, when you get it in a version of VS.Net that
> supports it. Might change your mind.


<snip>

I do find it amazing that pretty much every pro-E&C person I've heard
talking about it assumes that those who dislike it haven't used it, and
therefore pretty much don't know what they're talking about. I find
that an arrogant attitude, myself.

I have used it, and I believe it leads to bad habits - it leads to only
thinking about the quality of code when you're running the code,
instead of beforehand.

I'll probably find it useful when viewing a UI, so that I can change a
few behavioural things to see what feels best as a user, but as a way
of debugging I think it leaves a lot to be desired.

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


Nov 21 '05 #45
It's been an ineresting discussion to follow. Speaking from an end user's
point of view, I couldn't care less how sloppy the code is nor what form it's
in, I just want a simple interface for the enduser and an application that is
bug free. Maybe a bit more use of debuggers would help because there's a lot
of software out there that's not intuitive to use and is very buggy!

"Hareth" wrote:
C# 2005 express & vb 2005 express:
1. During runtime, I can edit my codes in C#..... How come this cannot be
done in VB? it says ...."read-only" during runtime......

2. Why does vb automatically show the errors, but C# i have to build the app
b4 errors are underlined in my code?

Nov 21 '05 #46

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eR*************@TK2MSFTNGP10.phx.gbl...
Sam,

"Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
I am totally with John and can't understand why Pro-E&C
people think we haven't used it.
Maybe you and some of the others used it. In the German C# community
there
are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.


Don't apply a small subset of the population to the population as a whole.
I have used it enough to know that it leads to really bad
habits


Depends on the programmer. Good programmers will write good code with and
without E&C, but will write code faster with E&C.


I disagree. GOod programmers that use E&C badly will write bad code faster.
Good programmers that use E&C correctly will notice very little productivity
increase.
Nov 21 '05 #47

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eH*************@TK2MSFTNGP10.phx.gbl...

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eR*************@TK2MSFTNGP10.phx.gbl...
Sam,

"Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
I am totally with John and can't understand why Pro-E&C
people think we haven't used it.
Maybe you and some of the others used it. In the German C# community
there
are some folks who never used it and who do not like it, because it's a
feature that was available in VB and is thus a bad feature.


Don't apply a small subset of the population to the population as a whole.
I have used it enough to know that it leads to really bad
habits


Depends on the programmer. Good programmers will write good code with and without E&C, but will write code faster with E&C.


I disagree. GOod programmers that use E&C badly will write bad code

faster. Good programmers that use E&C correctly will notice very little productivity increase.


Daniel, you are attempting to assert as fact something that you can neither
prove or disprove, when all the time you know it only as personal opinion.

you are close to becoming like the clock that once chimed 13 - it is a bogus
clock and now i distrust all times that i have received from it!

regards
roy fine

Nov 21 '05 #48

"Tom Dacon" <td****@community.nospam> wrote in message
news:eg**************@TK2MSFTNGP10.phx.gbl...
The teams that built the IDE interfaces for C# and VB are different groups
of people. They implemented feature sets that are different in some
respects, based on their notions of what their developers would want. The VB group apparently thought that the editor should show errors immediately,
while the code was being typed - it's more like VB6, and I must say that
that it's pretty handy, to boot. The C# group apparently thought that their developers would be coming from C++, where the VS6 IDE gives them
essentially no real-time help. They probably thought that their developers
would disdain that kind of hand-holding. You know: "REAL programmers don't
need squigglies!"


BUT - VC++ 6 had Edit and Continue - I remember the great fanfare when it
was anounced.

http://msdn.microsoft.com/library/de...vc6ed_cont.asp

Consider this summary from the link:

<quote>
Hopefully, this article has provided you with valuable information that will
enable you to take the greatest advantage of the Edit and Continue
functionality of Visual C++ 6.0. One of the best aspects of Edit and
Continue is that almost any Visual C++ user can benefit from it, whether
they know the feature is revolutionary or not. The result should be
smoother, less interrupted, and generally more productive development. That
has certainly been proven true here at Microsoft, where we've received
e-mail from developers throughout the company thanking us for Edit and
Continue. But they're a quirky set, so let us know how you use Edit and
Continue and how it's changed your development the next time you see a
Visual C++ team member at a trade show or conference.
<quote>

regards
roy fine
Nov 21 '05 #49

"Roy Fine" <rl****@twt.obfuscate.net> wrote in message
news:uI**************@TK2MSFTNGP15.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eH*************@TK2MSFTNGP10.phx.gbl...

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eR*************@TK2MSFTNGP10.phx.gbl...
> Sam,
>
> "Sam Gentile [MVP - .NET/C#, INETA Speaker]" <sa*@nomail.com> schrieb:
>> I am totally with John and can't understand why Pro-E&C
>> people think we haven't used it.
>
> Maybe you and some of the others used it. In the German C# community
> there
> are some folks who never used it and who do not like it, because it's a
> feature that was available in VB and is thus a bad feature.
Don't apply a small subset of the population to the population as a
whole.
>
>> I have used it enough to know that it leads to really bad
>> habits
>
> Depends on the programmer. Good programmers will write good code with and > without E&C, but will write code faster with E&C.
>


I disagree. GOod programmers that use E&C badly will write bad code

faster.
Good programmers that use E&C correctly will notice very little

productivity
increase.


Daniel, you are attempting to assert as fact something that you can
neither
prove or disprove, when all the time you know it only as personal opinion.

you are close to becoming like the clock that once chimed 13 - it is a
bogus
clock and now i distrust all times that i have received from it!


And you have yet to post any point what so ever. Your posts run between Ad
Hominem attacks and empty "good going" responses.

Worse yet, *YOUR* response was
"EXCELLENT POINT ! Best point made in this thread."

In other words, his opinion was somehow a good one while my disagreeing one
was distrustworthy? Is it perhaps that you believe the earlier opinoin while
disagree with mine? Do you not see how self-serving your stance is here?

I'm sorry, you aren't here to participate in discussion or even listen, you
are entirely concerned with supporting something based on your own raw bias
instead of facts or even well formed arguments. All you are trying to do is
discredit everyone who disagree's with you by any means possible.

And that is disgusting.

regards
roy fine

Nov 21 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Frank V. | last post by:
Hello, I'm new to VB.net, moving from VB6 to VB.net. My question is "In VB.net what is the equivalent of the App.major (and others) VB6 property. I, like a lot of people I imaging, display the...
2
by: lobrys | last post by:
hi I build a VB .NET application that makes file access, environnemet acess, database access, etc.... If I ran the app locally, everything works....(normal) If I copy the app on a server, and...
6
by: Rich Wallace | last post by:
All, I receive an xml doc with an element which contains a &amp; in the data. I am attempting to insert the data into a SQL Server database and I want to convert the &amp; to a "&" character before I...
17
by: orekinbck | last post by:
Hi There Say I want to check if object1.Property1 is equal to a value, but object1 could be null. At the moment I have code like this: if (object1 != null) { if (object1.Property ==...
3
by: Menu Chen | last post by:
我用LISTVIEW控件的时候,想限制用户对控件列大小的调节 但是找遍了LISTVIEW的属性,没有实现该功能的 另外,如果实在不能限制用户对列大小的调节的话,起码不要显示水平滚动 条,因为那会比较难看,可以吗?
9
by: Jim | last post by:
Hi folks! I'm new to this forum. I've programmed in VB starting w/VB1 about 9 years ago! ;) Certainly most time spent in VB6. Now trying to make the leap to VB.NET. Much harder than I...
8
by: Nathan Sokalski | last post by:
I add a JavaScript event handler to some of my Webcontrols using the Attributes.Add() method as follows: Dim jscode as String = "return (event.keyCode>=65&&event.keyCode<=90);"...
9
by: rn5a | last post by:
Is putting a VB class file in the special directory named App_Code the same as relocating the VB class file from the App_Code directory to another directory & then using the VBC tool, compiling the...
7
by: Charles Law | last post by:
This is a very basic question, but I can' turn up a statement on the subject: In C#, if I have If (x == 1 && y == 2) { .... }
5
by: Mark B | last post by:
Hi experts, I'm converting a homebrew AD management progam I wrote, from VB6 to VB 2008. I've got some code that sticks values in to Active Directory like this:- objOU.PutEx...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.