3 ms·
> "It saves me over and over again when dealing with code I don't understand." This is the key statement of the original post. If you don't understand the cod
by joblessjunkie 16y ago
> "It saves me over and over again when dealing with code I don't understand."
This is the key statement of the original post.
If you don't understand the code, then you need to sit down and read it until you do.
Using a debugger can lure you into quick, localized fixes to make small problems disappear. If you just need to make a minor fix to an external library that you'll never look at again, this is probably OK. But if you own the code, you're in a rut.
Constant use of a debugger is a crutch that prevents you from deeply understanding a problem or discovering core issues.
In the long run, a debugger slows you down. Don't step through code to verify fixes; write automated tests. Don't set breakpoints to verify that a value is what you expect; write assertions to confirm that they will always be so. Don't step through new code to verify it is correct; write a unit test first or compose your new code from smaller, proven pieces.
When confronted with a bug, sometimes the best thing to do is just stare at the ceiling and think about what might be causing it -- quite often you'll find the right answer.
Some bugs -- the really hard, nasty ones -- may never be revealed by stepping with a debugger. Performance problems aren't shown by a debugger. Only understanding your system at a high level can inspire you to make fundamental changes in your code. A debugger blinds you to these.
- ekidd 16y agoI agree with what you're saying here. However, when things start getting seriously weird, an assembly language debugger can be invaluable. For example, if your C compiler is generating bad code, or if you've violated some low-level assumption, it's hard to figure out what's going on by inspecting the source code. Sooner or later, the high-level abstractions break, and there's nothing you can do except single-step through the code that's going wrong. I once found a bug in MSVC++ while compiling Quake 2. The compiler was performing a tail-call optimization, but it hadn't noticed that Carmack had stored a pointer to a local variable in a global variable. The stack frame was overwritten while the variable was still live, causing weird stuff to go wrong. This is not the kind of bug that you can quickly find by staring at C code. :-)
- tonyarkles 16y agoThese are great edge cases, but certainly not the common case. I think, in general, people jump to a debugger well before they're ready to actually understand what the debugger is telling them. This turns into a random walk through the source and ends up being a pretty big waste of time, compared to actually reading and understanding what's going on. That being said, I'm planning on using gdb this afternoon to debug an x86 (16-bit) bootloader I wrote 4 years ago. It was part of a class project, and the prof ended up using it as example code. I think there are subtle bugs in it though...
- Raphael_Amiard 16y agoWhile i don't often use debuggers, i find your argumentation to be false, at least for me, for one very simple reason : A debugger can be a very fine tool for understanding how code you don't know works. Sometimes better than just reading it. Always better than litering the code with print statements.
- joblessjunkie 16y agoI don't mean to imply that a debugger is not an invaluable tool. But it's just one tool of many, and it's an addictive one. I once had to work for a few years with a development environment that didn't have a debugger. At first, this seemed like it would be impossible. But I learned ways to work without one, and now I find that I prefer them. Only rarely do I actually require a debugger. I do still pull a debugger out occasionally for particular needs, but by and large I find that I work faster with simpler tools -- or by just stopping to think for a moment before I reach for the keyboard.