Re: Question on vector at()
On Mar 18, 10:56 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
[...]
I think the important point is to understand what you are going
to write before writing it. I've seen a lot of second rate
programmers using the debugger to try to understand what they've
just written. That's wrong, and never gives good results. But
just writing random code, and then making random changes until
it passes the test suite isn't any better.
I agree, the point I was trying to make is it's often quicker
to redo a change that breaks unit tests than it is to debug
it. If this isn't the case, the change was probably too big,
or the tests too crude.
I'm not sure what you mean by "redo" the change. Do you mean go
back to the previous state, and start from scratch making the
change? That seems a bit wierd to me.
In my experience, there are really two distinct types of errors.
On one hand, there are typos and related types of errors. Your
basic approach to the problem was correct, but somehow, you
slipped up implementing it. Which of the unit tests failed, and
how they failed, should usually give a pretty good idea as to
where you slipped up, either a quick glance at the code reveals
it to you immediately, or you'll never see it (because you
generally see what you meant to write, not what is actually
there). In the latter, redoing the change could be a valid
solution, but generally, having someone else glance at the code
is even more effective---someone who's not looked at it before,
and doesn't know what you meant to write, and so really does see
what is actually there.
The other type is where there is a fundamental error in the way
you thought the problem out. The code correctly implements an
incorrect "design". In such cases, you probably will have to
back out and redo the change---trying to hack the code to change
the design generally results in a horrible mess. But before
doing so, you really have to think enough to be sure you know
why the design was wrong. (And again, talking it through with a
collegue who isn't so involved as to have preconceptions can be
remarkably effective.)
All in all, I find the debugger almost useless in the second
case. In the first case, if the unit test crashed somewhere
deep in a system function, a debugger can be very useful for
doing a post-mortem, to find out where in your code you were
when it crashed. And every once in a while (once in about
twenty years, in my case), using it interactively may help in
isolating where what you wrote wasn't what you thought you
wrote. (Another case where the debugger is useful is in
understanding third party software which isn't well documented,
or even well written, and for which you don't have any unit
tests. But of course, having the third party deliver well
written, well documented code with unit tests would be a far
better solution.)
The important thing, with the debugger or with any other tool,
is to think before you act. I've seen far too many cases where
the programmer will write some code, and then use the debugger
to try to understand what he just wrote. Where as he should
understand what he's going to write before writing it. I don't
use the debugger much myself, but if a programmer sits down, and
first works out what he wants to look at with it, and what he
expects to see, then I have no problem with it. If the attitude
is rather: the code doesn't work, and I don't know why, so I'll
step through it line by line in the debugger, hoping that will
give me some inspiration, it's the programmer you have to
change, before changing the code.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=EF=BF=BDe objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=EF=BF=BDmard, 78210 St.-Cyr-l'=EF=BF=BDcole, France, +33 (0)1 30 2=
3 00 34