A Taxonomy of Bugs

Summary

Debugging is often an undervalued skill. It’s not really taught in schools (as far as I know), instead, you kind of have to pick it up as you go along. Today, I’ll try to remedy that by looking at some common bugs and what to do about them. The default strategy I use with any bug is to: Try to find a way of reliably reproducing the bug so that I can break into the debugger when the bug happens and step through the code line by line to see how what it is doing differs from what I think it should be doing. Once you understand how the code’s actual behavior differs from your mental model of its behavior, it is typically easy to identify the problem and fix it. I know that there are some very successful programmers that don’t really use debuggers but instead rely completely on printf() and logging. But I don’t really understand how they do it. Trying to understand what the code is doing by inserting one printf() at a time and then re-running the tests seems so much more inefficient than using a debugger. If you’ve never really used a debugger (I know, they don’t teach these things in school), I suggest you try it! Get comfortable with stepping through the code and examining what it does. Of course, there are some situations where you can’t capture the bug in the debugger and have to resort to other methods, but we’ll get to that later, so let’s get started. The Typo Unlike most other bugs, the Typo is not caused by any flawed reasoning. You had the right idea, you just happened to type something else. Luckily, most typos are caught by the compiler, but sometimes your boo-boos compile: if (set_x) pos.x = new_pos.x; if (set_y) pos.x = new_pos.y; if (set_y) pos.z = new_pos.z; Once you see them, typos are trivial to fix. The hard part is seeing them in the first place. Typos can be hard to spot because just as when you read text with spelling errors, your brain auto-corrects the code as you read it. To be good at proofreading, you have to force your brain to go into a diffe...