Re:Debugging with Hypotheses
by greenyoda on Saturday January 17, 2015 @06:12PM
(#8905925)
"Again, do not fix if you do not understand."
I think that's the most important point of the article. If you don't understand the code you're fixing well enough to be able to explain what the bug does or why your fix fixed it, you'll have no way of knowing that (1) the bug (and not just a particular limited case of it) is actually fixed and (2) that you haven't introduced additional bugs by fixing the first one.
If you're reviewing someone's code and they can't explain to you how their fix removed the bug (e.g., they just changed random stuff around and the bug "went away"), that's a bad sign.
Re:Debugging with Hypotheses
by petercooper on Saturday January 17, 2015 @06:17PM
(#8905941)
In sleep, your “background mind” will process all the information you have gathered. I often find that when I come back to the problem the next day the solution jumps out at me.
This happened to me so often and in such striking ways that when presented with a problem now, unless the answer is obvious, I always say I'll be sleeping on it and, no, I won't be solving it today - it's interesting how many people think this is laziness at first, and will even tell you so, but are then thankful the next day when you come up with a creative solution.
Re:Debugging with Hypotheses
by phkahler on Saturday January 17, 2015 @09:20PM
(#8906361)
I once asked someone "how is this function used?" He put a breakpoint in it, ran the code, triggered it, and showed me a stack trace. "Here's how it's called." That was a nice specific example, but I wanted an understanding of intent or architecture or something he clearly didn't have. I almost never use a debugger, but my approach was developed in a time of 8-bit machines that didn't have debuggers. That said, I have seen bugs that could probably not be found without a debugger - including compiler errors.
I think that's the most important point of the article. If you don't understand the code you're fixing well enough to be able to explain what the bug does or why your fix fixed it, you'll have no way of knowing that (1) the bug (and not just a particular limited case of it) is actually fixed and (2) that you haven't introduced additional bugs by fixing the first one.
If you're reviewing someone's code and they can't explain to you how their fix removed the bug (e.g., they just changed random stuff around and the bug "went away"), that's a bad sign.
This happened to me so often and in such striking ways that when presented with a problem now, unless the answer is obvious, I always say I'll be sleeping on it and, no, I won't be solving it today - it's interesting how many people think this is laziness at first, and will even tell you so, but are then thankful the next day when you come up with a creative solution.