As every programmer knows debuggers are useful tools to step through
the program execution.
Some of the scenarios where debuggers are quite helpful are:
- While tracing a bug or error they are useful to pinpoint the exact
location of the problem in the source code. - They are helpful while trying to understand an unfamiliar code base
one is just getting started with it. - When one is learning a programming language debuggers are handy in
understanding the program flow. One can set breakpoints in the code
where results doesn’t match the expectation and understand how the
source code actually handles the data.
Given the value debuggers would provide to a developer why would
experienced developers have mixed opinions about them.
Here is what some of the experts say about debuggers:
“As a personal choice, we tend to not use debuggers beyond getting a
stack trace or the value of a variable or two. One reason is that it
is easy to get lost in details of complicated data structures and
control flow; we find stepping through a program less productive than
thinking harder and adding output statements and self-checking code at
critical places. Clicking over statements take longer than scanning
the output of judiciously-placed displays. It takes less time to
decide where to put print statements than to single-step to critical
section of code, even assuming we know where that is. More important,
debugging statements stay with the program; debugger sessions are transient.Blind probing with a debugger is not likely to be productive. It is
more helpful to use the debugger to discover the state of the program
when it fails, then think about how the failure could have happened. “
— Kernighan and Pike, The Practice of Programming
“Given the enormous power offered by modern debuggers, you might be
surprised that anyone would criticize them. But some of the most
respected people computer science recommend not using them. They
recommend using your brain and avoiding debugging tools
altogether. Their argument is that debugging tools are a crutch and
that you find problems faster and more accurately by thinking about
them than by relying on tools. They argue that you, rather than the
debugger, should mentally execute the program to flush out defects.”
— Steve McConnell, Code Complete
“An interactive debugger is an outstanding example of what is not
needed — it encourages trial-and-error hacking rather than systematic
design, and also hides marginal people barely qualified for precision
programming”
— Harlan Mills (Quote from Code Complete)
Like many programmers I also used the debugger very frequently. While
programming with Perl I had used ptkdb and while working with Java I
used Eclipse which has an excellent visual debugger. But things got
changed when I started programming with Python. I got bitten while
debugging some Python code, which made heavy use of decorators, using
visual debugger that came with the IDE (it was not Eclipse). After
wasting a considerable amount of time I realized that the code flow
using the debugger (probably due to a bug in it) was different than
how the program would behave when it was executed. With that
experience I dropped the IDE and switched back to world’s most
customizable editor 🙂 and also stopped depending on the debugger
altogether.
Ever since then I have used the debugger very sparingly. At the same
time there have been no dearth of issues I faced with the code I
worked, developed.
These are some of my learning I got ever since I stopped being
over-dependent on debuggers:
- Frequent usage of debuggers prevents one from stopping and thinking
about the code one is developing (or having issue with). When the
debugger was handy my first reaction when faced with an issue was to
fire the debugger and launch the code trace with it. I have now become
more disciplined, pay more attention to the stack trace and try to
trace issues by adding print statements and spending more time
thinking about possible code flows that would result in the problem. - As any one who has programmed and faced issues would tell that a
reasonable amount of problem solving also happens when one is not
sitting in front of the monitor and actively coding. When one is quite
involved with a problem, thoughts about it linger even when one is away
from the monitor (say during commute or in shower etc.). Quite often a
solution or hint about possible solution come to mind in those
monitor-away moments. What I have realized is that when I don’t use
the debugger I have more context in my mind than I would have if I
were using the debugger. This helps me in thinking better approaches
toward solving the problem and think of more possible ways in which
something would have gone wrong. - Not using debugger has made me to trace the root causes for an
issue far more quickly.
Does this mean that one should never use a debugger as they prevent
one from getting a bigger picture. I don’t think so and I don’t go as
far as to suggest that one should avoid debugger at all costs. I think
use of debugger in moderation , not using as one’s first line of
action when faced with a problem and always trying to view the problem
one is facing at the right context (with or with out debugger) are
better approaches to debugging.
If you are frequently using the debugger, stop reaching for the
debugger and see if that makes you a better developer.
Also see an interesting discussion in StackOverlflow about debuggers:
Debugger mother of all evils
