3 ms·
It depends on the nature of the bug. If it's some behaviour that has changed then i try to isolate it to a test case, if one doesn't already exist. I can then u
by leejo 11y ago
It depends on the nature of the bug. If it's some behaviour that has changed then i try to isolate it to a test case, if one doesn't already exist. I can then use git to automatically bisect to the offending commit which, nine times out of ten, makes it immediately clear where the bug is. The net result is the bug being fixed and a useful regression test to make sure the bug stays squashed. And i got the vcs to do most of the work for me.
If it's something i think is trivial i'll just use a few print statements. This is 90% of the time.
If i end up with too many print statements then i step into the debugger. Others scoff at debuggers, which is odd because they can be powerful tools. Maybe you only use it once every couple of months, but they can be very helpful. When you're waist deep in the stack, or dealing with action at a distance, trying to fix something in poorly factored code, want to watch a variable, think there's some weird timing issue, need to step down into libraries beyond your control, then debuggers can help.
Don't think of the debugger as a debugger, think of it as a REPL. You just happen to be using the REPL with buggy code.
- greenyoda 11y ago"Don't think of the debugger as a debugger, think of it as a REPL." That's a great analogy. "You just happen to be using the REPL with buggy code." Despite the name "debugger", it's not just for buggy code. A debugger can be a very useful tool for understanding how someone else's code works.