Robert C. Martin weighs in on debuggers:
"I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habit of depending on the debugger instead of on their brain."Martin's essay reminded me of a fellow I worked for briefly early in my career. He wrote one of the first personal computer database packages (and became rather wealthy as a consequence). When I asked him about his work habits and philosophy, he told me that he'd single-stepped through every instruction in the application at least once. He also said that he didn't see how anyone who called themselves a professional wouldn't do the same.
I've though about that occassionaly over the past few years, as I've noticed that I'm getting a lot done without ever reaching for a debugger. Taking small steps and writing lots of unit tests helps a lot, even when working with languages that don't have safe pointers and built-in garbage collection. Writing the tests first as a way to develop testable APIs shakes out a lot of silliness before it has a change to grow into one of those "what in the heck was I thinking?!?" moments.
I never realized how much this influences my coding style until I was recently in front of 30 people at a client location, writing some complex code in real time for them. I'd write three or four lines of code, run the program, then either rewrite those three or four lines if they didn't do what I expect, or I'd write three or four new lines if they did.
While this was "normal" for me (even before all this XP craze), it was pointed out to me about my "radical way of programming".
Maybe that's why I never understood why people spend all that time in debuggers. I've never needed one. I just don't outwrite my brain, and always have something to test after a few minutes more work. If I need, I add YAML (formerly Data::Dumper) and dump a data structure that seems odd.
Of course, in the process, I build a lot of scaffolding that I later tear down, but that's no problem because my overall progress seems far faster than doing it the "hard" (to me) way.
Re:Good analogy
djberg96 on 2003-12-14T23:02:17
My counter to this would be that you're often debugging *someone else's* code, and that's where debuggers can be a lifesaver, or simply help you find a bug in someone's module on CPAN.I sometimes use a debugger as a way to graphically represent complex data structures that I don't understand and I'm not sure how deeply nested they are (i.e. where print statements won't necessarily work).
But on the whole, yes, they can make you lazy.
Re:Good analogy
jplindstrom on 2003-12-16T18:18:44
I guess this small-steps way of doing things kind of requires a language like Perl where you essentially have no compilation step to prevent you from seeing what you just did.
In a way it resembles the way of writing HTML: write, save, switch to the browser and reload in a quick sequence.
So using a language which takes longer to compile, like C++ in a lot of cases, breaks the cycle, forcing you to write more and more code to justify a compilation (thereby verifying that you didn't outwit yourself).
Re:Good analogy
dws on 2003-12-17T00:16:01
Yeah, quick turnaround on the compile/link/run cycle is essential. I've been able to do Test Driven Development in Perl, Java, and now Python, but have thus far avoided the opportunity of trying it in C++.It's amazing how comforting it is to know that if you find a problem, changes are really good that you caused it within the last few minutes, and that you only have to take one step back.
Re:Good analogy
jplindstrom on 2003-12-17T21:34:40
Anyone with success stories of TDD in C++?
I'm think I'm about to get involved in that in the near future, and I'd appreciate any practical tips and tricks.
