Ask HN: What's the *right* way to debug a program? - uptownfunk
======
halpme
Reproduce the bug. Reproduction steps/environments are usually provided by
support engineers or QA. Look through log files for any specific error
messages, and use grep to find where in the code the error is coming from if
it's not specified in the exception stack trace or something like that. Look
at the code and form a hypothesis about where the bug might be located (use a
"binary chop algorithm" discussed in books such as Code Complete and Debug
It). Create breakpoints and step through the code with a debugger and record
your observations. If you still haven't found the bug, use the data you just
collected to form a stronger hypothesis and repeat the process until you've
identified the source of the bug. Then apply the fix, and run some unit (or
integration?) tests to verify you didn't introduce a regression or that you
actually treated the symptom instead of fixing the root of the problem.

This might not be the best approach, but it generally works for me. I highly
suggest reading the following books: Debugging, Debug It! and parts of Code
Complete.

------
Rannath
There is no _right_ way to debug. Whatever finds your bugs works.

Personally I use whichever debugger I have on hand with breakpoints and walk
through code to see what's going on, that usually lets me find my bugs fairly
quickly. Of course the first step is reproduction of the bug, which can
sometimes be hard.

------
beamatronic
It depends on the kind of program. Is it client-side, server-side, is it a
console command line application or a daemon process?

~~~
greenyoda
Or a Linux device driver, or embedded code running on a microcontroller...
lots of different kinds of programs out there.

It also depends on the language that it's written in. For example, gdb is good
for debugging C or C++ or assembler, but you probably wouldn't use it to debug
a Lisp program (unless you were a masochist).

