"Dan Tex1" <dantex1@aol.com> wrote in message
where your program was when it crashed, and then the source of the error is
obvious.
If the problem is not a crash but wrong results, then the debugger will step
through the code, but generally more slowly than if you do it by hand. They
are also often themselves either bugged or difficult to use. However when
they work they are of course accurate - no missed semicolons messing up your
dry-run.

Then of course if you do non-hosted development, you have the problem that
debuggers might not always be available.

"Malcolm" <malcolm@55bank.freeserve.co.uk> wrote in
news:bi0dnf$tvg$1@news7.svr.pol.co.uk:

You also forgot to mention how debuggers can affect the actual results
themselves and can make problems harder to find than analysis without them.
This is particularly true where timing is a factor, whether it's
explicitely understood or not.

Learning to debug without using a debugger is a definite must for any
programmer IMO. Partly because you learn how to analyse code for
correctness without having the ability to 'inspect' it's behaviour. Another
big part is that making debugging difficult forces you to make fewer bugs!

Ian Woods

William Cleveland <WCleveland@Ameritech.Net> wrote in
news:3F440216.5040907@Ameritech.Net:

My bug rate is pretty small. I know why it is so: because I've practiced
writing code with the expectation of it working first time. Part of that is
because debugging in the environments I use is extremely non-trivial.

Having a nice suite of tools to help you debug is very nice. However, it's
better to have never put the bugs in there in the first place. From my
experiences it seems to be quicker and easier. I don't know about you, but
the one part of coding I find frustrating is debugging! The less of it I
do, no matter what tools are available, the happier I am.

Ian Woods

On Thu, 21 Aug 2003 02:44:46 +0000 (UTC), Ian Woods
<newspub@wuggy.org> wrote:

as a programmer. If you were the hot shot programmer you think you
are then your managers would be giving you other peoples bugs to fix.


--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.

Thaddeus L Olczyk wrote:

Indeed. I *love* debugging--it's like playing detective! (-:

The irony is, after almost three decades of programming, the bugs
I write are usually brain farts or typos and are very easy to find,
OR are real head-scratchers that take hours and many swear words.

On the other hand, those last are fun once you do find them! "The
Great Hunter finally tracks the wily beast to its deep lair..."

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

Ian Woods wrote:
No, that depends on your coding habits. If I have an IDE debugger
handy, I will generally trace through each section of code at least
once, watching to verify that it does what I meant, before I ever
let it run a full-speed test.


So you think about those. That doesn't mean you can't use the
debugger for others.


in the first pass. I'd rather not concentrate so hard on getting
the current line perfectly correct that I forget what I was going to
do next.

The traditional way to do this is to write pseudo-code, and then
translate it to real code. I think my approach has the same
benefits with better efficiency, especially when the tools
support edit-and-continue.

Bill

Ian Woods wrote:

I don't think that follows at all. I love debugging, but I sure
make every effort when coding to avoid having to do so. It's just
that when you do get a worthwhile bug, it gives you a chance to
use a different skill set, and that's a nice change.

Humans make misteaks. (-:

Not so. A debugger can allow you access to parts of the system
your tests can't touch. For instance, a debugger allows me to
inspect the stack, the heap AND trace into the library.

So do I. I don't view the debugger IN ANY WAY as a safety net.
It's JUST another tool at my disposal.

Because we're human! (-:

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

Programmer Dude <cjsonnack@mmm.com> wrote in news:3F462B1A.ACB3ED10
@mmm.com:

What's a bigger motivation to get your code right first time around than
both wanting to write perfect code (the carrot) but also disliking the
process of finding error (the stick)? For many people, one is enough. For
me, and I suspect for many others, having both produces better results.

Coding in an environment where even getting debug output from the system
is virtually impossible had shown my reliance on debugging tools to cover
up for mistakes I'd been making. I had the tendency to focus on locating
and then simply fixing the code rather than fixing the reason why the
code was broken.

I've made myself dislike debugging, or rather, the 'causes' of debugging
as part of that. Now, everytime I find a bug, I don't just fix it. I
determine it's cause and do what I can to eliminate it by altering my
programming style and the schemes I use to organise code.

Disliking debugging is definately useful if your goal is to stop making
the kind of errors debugging requires.

Other humans make me steaks too. Or, at least cook them.

When you use a debugger you're seeing the state of the system at various
points during execution. You've still had to supply data. Your debugger
won't show you behaviours produced with different data - a single test.
Your tests do touch all these things, since they all need to work as
expected for the tests outcome (if it's well designed) to be fulfilled.

Debuggers are useful for finding bugs which have already been
demonstrated. They're not very useful for finding bugs which haven't
since you still need to supply data in to produce the erroneous state.

Indeed. However, it's a tool which I found made debugging too painless to
provide motivation for not making mistakes. Bugs I found and fixed with
this tool were never analysed and their causes removed so I kept making
them.

We might be human, but I don't think it's a good excuse for shipping
broken code. Afterall, against all the odds we can write robust stable
code.

Ian Woods

Ian Woods wrote:

As already noted, humans are fallible.

Then it's not the act of debugging that is frustrating... it's the
discovery that you are human, and therefore fallible. Get over it.

Uh... bollocks.

See the above, then tell me if it's possible that a human might neglect
to include every single possible case when testing a piece of code.

"I've run 53 tests on this thing. It's bulletproof!"

"Did you check for a buffer overflow in this bit?"

"Err..."

And does you code /always/ work right first time? Do your tests
/always/ catch the errors in your code?

Additionally, how much of your development time do you spend devising
tests for every tiny part of your code? Is it conceivable that the time
you spend on that could be just as much as I spend running it through a
debugger?

If you are one of the very, very few people who can write flawless code
first time, every time... then you probably don't need to bother with a
debugger, or with unit testing, or any of that nonsense.

If on the other hand you are like the rest of us, then you need some
tool for proofing your code. That means testing... either in code, as
you seem to prefer, or with a debugger.

--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

Corey Murtagh <emonk@slingshot.co.nz.no.uce> wrote in
news:1061693563.655472@radsrv1.tranzpeer.net:

Indeed. That doesn't mean that trying to be infallible is a bad idea.

I don't like making silly mistakes. I do what I can to avoid them.

I can't see how anyone can say that this is a bad thing to do, especially
since in programming where being consistently correct is a requirement
for writing working code.

Everyone knows the answer to this question - your tests might not find
all the problems either.

This doesn't mean programmers shouldn't bother putting in every effort to
write correct code the first time. If a programmer has put in this
effort, then it's less likely that their code will have problems,
regardless of whether the tests are well designed or not.

Another question that has the obvious answer - of course not. My tests
don't always catch all the errors in my code either.

Neither of these has anything to do with whether or not I should try and
write code which doesn't have any errors to start with.

I don't. I probably do far less than average black and white box testing
on my code.

A different, but interesting question might have been "how much of your
development time do you spend writing code?". Almost all of it. I spend
less than 20% of my time testing code for if it works. I spend much more
time on testing the mathematics which the code was derived from, which is
a completely different kettle of fish.

Not likely, since running I'd already need the tests at hand to make
running it through a debugger meaningful. There's little point viewing
the code for a test the code passes perfectly. When I used to use
debuggers a lot, whilst I was stepping through I would find bugs in the
code even though the test would run perfectly. All I was doing though,
was critically analysing the code. I don't need a debugger to do that.

Certainly, a debugger can help you track down problems when you know what
the problem is and can reproduce it. I'm not going to say stop using them
because they are useful. The only thing I'd say is that instead of merely
'fixing it and moving on', which is how I used to use them, that looking
at the problem, at why it occured and how to ensure it doesn't happen
again next time. That way, you don't need to pull your debugger out to
find the problem because you'll be less likely to make it again.

I'm not one of those people. I might be one of those people who endeavour
not to make the same mistake twice and so wind up making few mistakes
habitually.

I really don't see how a debugger can be used to test code. Could you
explain to me how you use it so that I may see the light?

Ian Woods

Ian Woods wrote:

For me the former is *plenty* sufficient. I have worked with code
that--due to real time issues--didn't lend to a debugger, and I've
worked with systems where one (or a usable one) wasn't available.
My coding style is the same in those cases as it is when I have a
good debugger available. (Actually, I guess you could interpret
that two ways.... :-)

I can't argue with that!
(I do argue with the very first sentence quoted above.)

I think that's a great idea!!


Er, yes. What I was getting at, though, is that a debugger allows
you to inspect parts of the system you cannot access with tests.


Absolutely. I only use a debugger when an error occurs (often via
testing...hopefully always, but.... [shrug]). IME, jumping into
a debugger with a breakpoint just prior to the suspected problem
area is a *very* fast way to find out the exact nature of the bug.


Well, in your case debuggers probably *are* a Bad Thing, then. (-:

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

Ian Woods wrote:

Ian, I think those are not necessarily related concepts. It would
be just as easy to--having analysed the bug with a debugger--go on
to analyse the cause and diagnose a means of Not Doing That Again.

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

Thaddeus L Olczyk <olczyk@interaccess.com> wrote in message news:<9or9kvgu9src7h1jeeq451pbgp6k2tq12b@4ax.com>. ..
<snip>

Hmmm that sounds a bit harsh. Needing to debug, implies something has
gone wrong; and being human, I'd say there is no one who really likes
it much when things go wrong - at especially the wrong times. Things
get really frustrating if you have one of those head scratching bugs,
that you have been trying to track down for hours and got many false
positives that looked like the solution but were in fact not.

I think one should have no business working as a programmer if they
*refuse* to accept debugging as part of *their* responsibility and
expect that *someone else* will do it for them.

Quite ironic isnt it? If one is a hot-shot programmer, then they
typically dont have bugs in their code and can be free to write new
code. But since they are a hot-shot, they would know how to fix
other's bugs and so actually end up doing bug fixes instead of writing
new code. Kinda makes you not want to be a hot shot eh?

Cheers,

Eric

Programmer Dude <cjsonnack@mmm.com> wrote in message news:<3F44FEA2.A7B47A25@mmm.com>...
I've been at it for just 6 years and I'm already seeing that
phenomenon. You either get a bug you can fix in 5 seconds or one that
needs 5 hours - nothing in between. One really hasn't programmed until
they find themselves awake at 4.15am, having been at the computer for
hours on end, and having traced through the same code hundreds of
times and *still* cant see what's wrong

I think that is why I remain a programmer. Writing code that works
first time makes you feel like "damn! I'm good." But writing code that
you got to work after hours of debugging? Best thing since sliced
bread

Cheers,

Eric.

Programmer Dude <cjsonnack@mmm.com> wrote in message news:<3F462B1A.ACB3ED10@mmm.com>...
<snip>
Tracing into the library is pretty cool! I have learnt *lots* of
things by being able to trace into the C/C++ standard libraries in
VC++ 6. It gave me a bit of a fright the first time I discovered it. I
was tracing through a small program, then pressed the "step into"
shortcut key, when execution had reached a "printf" call. All of a
sudden, reams and reams of code came into view!! I saw how printf and
a bunch of other functions in the C standard libraries were
implemented - it was an open source heaven and I got hooked (maybe too
hooked because I later traced into the C++ STL and was immeditely put
off by the jumble of code that is the STL, LOL)

and because no one *wants* to make errors - we just make them whether
we like it or not. If making errors was an option, we wouldn't need
debuggers!

Cheers,

Eric

Eric wrote:

"Hey, what's that light coming in the window? Damn, it's tomorrow!!"

--
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|___ ____________________|

Programmer Dude <cjsonnack@mmm.com> wrote in message news:<3F5E467C.189B5B6C@mmm.com>...
Words that are all too familiar