🚀 go-pugleaf

kenslowe@internet.OIT.OSSHE.EDU (Eric Kenslow) wrote:

>tangent@cyberport.com (Warren Young) wrote:
>
>[snip - interview in DDJ with Michael Cowlishaw]
>>Anyway, a relevant quote from the article: "One question I often ask a
>>programmer is, 'How good are you at using the debugger?'  If they're
>
>	'The best way to write but-free code is to actively step through all
>new or modified code to watch it execute, and to verify that every
>instruction does exactly what you intended it to do.'

This is also true, but I don't know that this would make you an expert
debugger driver, either -- after all, you're just single stepping and
maybe watching some variables.  

I use Borland C++, so I have two debuggers: a separate, high-powered
one and a weaker one built into the IDE.  About the only time I use
the high-powered one is when I'm battling a serious program crash,
often one that brings down the rest of the system before I can figure
out what happened.  (The separate debugger can sometimes keep the
crashing program from bringing the rest of the system down, and the
rest of the time offers more low-level tools like memory breakpoints
that can help here.)  This sort of  problem doesn't happen under
"real" OSes (no flames please), which is what Mr. Cowlishaw usually
uses.  I suspect that that colors his viewpoint some.

Only rarely do I use anything more powerful than the stepping and
basic variable watch commands.  The separate debugger especially has a
lot of functionality I haven't even touched yet.

>	In short, I think that a sweeping statement like 'debugger jockeys are
>bad' misses the mark, 

No sweeping statement is perfect (except for this one), but that
doesn't mean that there isn't some truth to them.  Glean what truth is
in the statement, but no more.

>because a debugger can be used for actively
>verifying code correctness as well as finding out where you screwed
>up.

The debugger is in this case is just acting as a more visual version
of what thorough programmers already do: visually step through the
code to verify paths and such.  If it's easier for you to use the
debugger for that, then by all means go to it.  Aside from being more
visual, it gives you a more "sure" feel as to the code's correctness,
because you've seen it execute as it should, at the instruction level.

Personally, I think that debuggers are a nuisance (slow, lots of
set-up, loops are a pain, etc), and the benefit isn't big enough for
me to fire it up for code verification.  It's faster and easier for me
to do it by hand.  Maybe if I was writing code targeted for reusable
libraries I would do something like that, but then the solidity of the
code would be more important to me.  Fred Brooks' rule of libraries
being three times as hard to write as application code applies here.

= Warren --