| Title: | Debuggers |
| Date: | June 5th, 2001 |
| Self Righteous: | 1 |
| Opinionated: | 8 |
| Simply true: | 3 |
I'm not a big fan of debuggers.
I used to be from the somewhat shameful school of "printf-debugging," but I think I'm beyond that now.
Perhaps I'm just fooling myself though.
People often ask me what debugger I use - and I generally avoid them if at all possible, unless I can't.
Times when I can't:
But other than that I use a very different design paradigm that allows me to avoid debuggers in general. It's kind of an extension to the "modular design" approach that is touted in college. (Kind of like OOP, but not in terms of just dealing with data).
It's pretty simple. Design every piece of your program as a separate entity that can stand on it's own, and, more importantly, can be tested on it's own.
It's similar to the block design method that complex chips use, and it's pretty handy, since chips, once fabbed, can't exactly be run under a debugger.
The consequence of this, taken to an extreme, is staggering. It means significantly more work up front, but it means that in the end, you are simply playing with legos. I like that, because I like legos, and I grew up playing with legos, so I'm good at it.
When you encounter a bug, it's merely an issue of isolating the broken component or interconnection, and then, if necessary, testing that block by itself - a simpler task that generally doesn't require a debugger.
There is another cost that should be recognized - you have to make sure all of your pieces fit together. If you don't like looking at your code from the top down, then this isn't a very good technique.
And finally, I've realized that my tendencies make it difficult for me to pick up a debugger at those times that I should. I can only accept this as a weakness on my part. Oh well.