If you write programs, a large portion of your time is spent testing your code, and finding and removing bugs in your program. Not being able to understand a bug is one of the more frustrating experiences you can have as a programmer. I’ve been on the lookout for ways to reduce the amount of time I spend debugging, but I really haven’t seen any good articles on the theory of debugging. Here’s everything I know about debugging. If you have additions, feel free to leave a comment.
Write better code
The best defense is a good offense – if you write your code in a clear and concise way, and write by making incremental changes which are immediately tested, you are less likely to run into time-sucking bugs later on. Some people recommend test-driven development and code review as ways to cut down on the number of bugs that make their way into programs. Remember, the earlier you can catch bugs, the less expensive they are to fix.
Try simple fixes for 2-3 minutes
Some bugs are simple and can be fixed within minutes. I would recommend spending 2 or 3 minutes trying a few simple fixes before bringing out the big guns. Yes, this is “cargo cult” programming but maybe 50% of the bugs you find have trivial fixes, and it might not be cost-effective to bring out the big guns right at the start.
Set up a reduced test case
Try to set up the simplest possible version of your code that produces the error. In HTML and CSS, this is known as a reduced test case. This often involves deleting large swathes of your code, so I would recommend either copy/pasting to another page, or committing the current version of your code, then making changes, and reverting to the original version once you’ve identified the problem. If you have a unit test suite, this would be a good time to add a new test case to the suite.
Use print statements or a step-through debugger
If setting up a reduced test case is not feasible (multiple dependencies or complex code), use print statements to determine the values of variables before and after all method calls in your program that could be causing the bug. This is tedious, but systematic, and preferred to cargo cult programming, where you make changes at random and hope that they solve your problem. Another approach is to use a step through debugger – stop the program at a point where you know the output is correct, and then step through the program line by line, monitoring the information in the program. In python, the pdb module does this. In Java, the DrJava program is looked down upon for being mostly for students, but I’ve found it extremely useful for viewing the values of variables at points in the program. Most programming languages should have a step-through debugger.
Use assert statements
Alternately, you can use “assert” statements to assert that a variable should have a specific value at a point in your code. This will stop code from executing immediately at the point where a variable has an incorrect value. This has the added benefit of making sure you understand your code.
Concede defeat
If you’re still at a loss, consider ways in which you can “go around” the bug, by rewriting sections of your code in a way you understand, or trying something else entirely to solve your goals. Note: I struggle with this because not knowing the cause of a bug drives me up a wall, but you might have some success with it. Also, stepping away from your computer and thinking about the problem in more abstract terms can help – I’ve had some luck with just taking a shower and thinking through the problem.
Ask the Internet for help
If you’re still at a loss, try copying and pasting your error message into Google, or posting on StackOverflow. Be sure to be explicit about what you expected to see and what actually happened, and post the code of any error messages you might have. You can also try the IRC channel for the programming language, but I’ve had less success with this – there might be someone nice who’s willing to help you out, but more often than not your message will be ignored.
About me
My name is Kevin Burke and I’m a senior at Claremont McKenna College. I started programming in January of 2010. Read more about me, or follow me on Twitter here.
Liked what you read? I am available for hire.
Comments are heavily moderated.