Michael Culley said:
I think EnC is the biggest productivity improvement that could be made to
C#. The number of times I run a project and go through a
series of steps just to find I've made a minor mistake is quite large. I
then have to exit the app to make the change and start
over.
I must ask, why are you testing that way? Shouldn't you be testing all your
individual chunks of code in a more modular way instead of running from
point A all the way to point X? Outside of errors in the UI(which are hard
to test outside of debugging), I don't think the approach you use here is as
good an idea as you seem to.
Furthermore, E&C doesnt fix the situation, which isn't uncommon, where the
code that causes the error actually occurs in the first few lines of the
program, even if the manifestation of that error doesn't occur for 6000
lines. That is much more the kind of thing you should be stomping around a
debugger for, IMHO, and chances are pretty high you are better off
restarting the whole app than trying to jump back that far(if its even
possible). Who knows what kind of bugs you'll add.
I've been reading about EnC (or the lack of it) since .net beta was
released and the posts against it always have a common theme.
There is always this "I check my code thoroughly before I run it". In my
opinion this is newsgroup bollocks along with such gems as
"I always spec out my projects to last detail and changes to the spec are
rare". If I've written a slab of code the easiest way to
check it for mistakes is to run it. 90% of the time there is something
minor wrong that needs to be changed. EnC would save a lot of
time.
Neither of which I said, I simply said I don't use the debugger enough to
justify E&C. I do not(and abhor the practice, incidently) test my code using
a debugger, that isn't the purpose of the debugger(which is to help find the
cause of bugs, not to find the bugs themselves). On larger projects I only
use the debugger when a unit test fails and my glance at the code doesn't
suggest that I did one of the many stupid possiblities that you
suggest(wrong value, wrong method, or even the occasional accidental
infinite loop), or a user test does, often times the debugger is more
valueable in the last case, but that last case is probably somewhere around
5 to 10 times less likely than an unit test failing. On smaller projects I
prefer to run the app and use it instead of jumping immediatly to the
debugger and patching till it works right. If there is a failure I *rethink*
the method instead of hacking away at it as E&C can, and sadly often does,
promote. This is helpful in another way, to be blunt, most of the time the
first implementation of a method you write isn't the one you should be
using, which si another thing I think abuse of E&C promotes.
Perhaps if developers were a bit more disciplined it would be possible to
add E&C without getting people paranoid, but I know for a fact(I, for one,
made these mistakes myself the first few VB6 apps I did), that the majority
of users are going to abuse it, badly. I don't think I've seen source for a
VB6 app that didn't look like it had been written half under E&C. People
start to write code *for* the debugger, in the debugger, instead of
addressing the problem that their code just isn't right. That is one of the
biggest problems with edit and continue. Beyond that, people seem to love to
just slam out code and run it, not bothering to actually think about what
they are writing, catching the little mistakes that are left behind. In my
own experience I tend to write less silly little mistakes when I'm in a
langauge without E&C, mainly because I can't rely on that net and I actually
have to consider my code. You don't have to check it throughly before
running(that is pretty infesible at times), but you really should be
checking it while you're writing it, don't you think? Or, at the least,
glancing along the last 5 or 10 lines to see if you wrote what you meant to,
something similar to what I'm doing right now as I write this reply. I
certainly don't have an english debugger waiting to run over it so I can
make sure I didn't write something legal but stupid. Its up to me to read
what I'm writing, to understand it and to make sure it fits in with what
I've said before(mercifully, english readers are more forgiving than C#
compilers. However, english is considerably more complex, unlike the
compiler I doubt anyone reading this actually knows all the rules). That is
part of your responsibility, not the debuggers, to ensure you wrote what you
meant to while you are writing.
Anyway, tell me, what arguments do you have for it? Just the "I hate having
to restart when I screw up" argument(which, incidentally, is the only
argument I've ever heard in favor of E&C; not that it helps find bugs, but
that its easier because minor screwups can be fixed and likewise ignored
while writing, or perhaps hacked around)? Does that really justify E&C? Is
it enough, given the enormous potential for abuse, to make E&C a "good"
feature? Enlighten me, be the first to provide an actual reason.
And, at that, if you think all of the above is bollocks, then I respectfully
state you should try it and see if your code quality improves, rather than
assuming that easy is best.
.
We could remove a whole rash of features because they are abused and most of those would be abused far