Purposefully debugging without using a debugger?

Question

In chapter 5 of \"The Practice of Programming\" Brian Kernighan and Rob Pike write:

As a personal choice, we tend not to use debuggers beyond getting a st

Answer 1

For the average little silly bug, it's faster for me to read the code over 2 or 3 times, debugging in my mind than to fire up the debugger and get the program into the required state.

Answer 2

Print statements tend to produce output that you can look at and reason about for quite some time, whereas when using a debugger you are forced to memorize the past, know exactly what is going on at present, and exactly what should happen in the future.

For example, you have an algorithm that changes a variable 100 times. On the 85th time, it got changed to a value that should never have been assigned to it in that case. With a debugger, you are forced to step through that 85 times. Conditional breakpoints may alleviate some of this.

Answer 3

It depends on the situation for me. Using Visual Studio I tend to use the debugger far more than I do when programming in any other language, or OS. I almost never use it when I program in Linux. It is usually just faster to read over the bit that screwed up and analyze it in my head. I only ever fire up a debugger when it is some kind of strange pointer array related issue (ie: the XXth entry in a pointer array is wrong for some reason) that I can't see at first glance.

That said, in Visual Studio, unless the bug is very obvious, I find that it is just as fast to throw in a breakpoint, and try what I was doing again to see what's happening.

tl;dr: my reason for using a debugger as a last resort, is speed.

Answer 4

When I have a reproducable scenario I definitly use the debugger to track down that bug. Otherwise it is basically used only to get a stack trace from a core dump.

Traces are the basis to start to work on an issue

NB Embedded application in vehicle.

Answer 5

I rarely use a debugger simply because we do not have one that we can attach to a live system. We can load an image and use the debugger to calculate offsets inside of structures, or translate a program counter to a file & line number. But in general, we code defensively, log errors, and keep a lot of statistics so we have a chance of diagnosing a failure post-hoc.

Having a working debugger, or an emulation environment, would have occasionally saved me days or weeks of twiddle, reproduce, diagnose.

Answer 6

My favorite feature of the Visual Studio Debugger is the Immediate Window. I'm not sure if this is provided in many other environments, but it is damn helpful sometimes.

A few examples of how:

• Data coming back from a database isn't casting correctly. Fire up the debugger and try a few casts until you get the right one (oops the int was short or the bool was a byte, etc),

• Web apps with nested controls (e.g. TemplateFields in a GridView)...I have a reference to a specific control but want to get the grid row that I'm in (or viceversa). I can code a few nested FindControls() and hope for the best, or I can just do it in the immediate window until I find the control that I want.

Every project I've worked on so far (only 1-2 years corporate experience), I've used the debugger/Immediate Window at least once or twice. It may just speak to my inexperience, but I find it's extremely helpful for getting a good understanding of what is happening in a complex system.