How to Debug Code
Okay so your code has a problem. Here’s a general guide on steps you should take.
Run the code and reproduce the problem
This should be obvious but you need to be running your code to debug it.
Look at any logs or output for error messages
For backend services, this log will probably be sent to standard error in a terminal or written to a log file. If you are running in a docker container, you might have to look at the logs using docker commands.
If you are working on code in the web browser, check the JavaScript console in the browser developer tools.
Identify the file and line number the error occurred on
Usually errors contain a stack trace of all the files and functions that were called when the error occurred. Try to pin point the line of code that triggered the error and exactly which file it was. This can sometimes be difficult if you are using a framework which dynamically calls your code. If this is the case, you might have to dig a little deeper.
Print out any variables relevant to the bug
On some line above the bug, print out any variables that are used on the line that is causing the problem. Sometimes in some languages you might need to import some kind of functionality to help with the printing out of complex data structures such as dictionaries, hashmaps, structs or arrays. When printing them out, make sure to print out the name of the variable as well as the value, as this will make it easier to find it in the log output.
Use a debugger
If print debugging isn’t doing it for you, it’s time to break out the debugger. This is easy on some languages and harder on others. It is worth your time to figure out how to setup the debugger on a project if you use that language every day. Here’s the basics of how to use the debugger, regardless of what type of debugger it is:
- Set a breakpoint above the line of code that is erroring.
- Inspect the variables and their contents that are in memory when the debugger stops
- Step through the code line at a time, checking to see if any variable change unexpectedly
Watch out for try blocks
If your language uses exception handling, you might include a try block that catches errors. If an error occurs in the try block, and you don’t print it out in the catch/except block, you are hiding useful error information. Most languages let you grab a copy of the error and print it out. Do this. In fact, never add a try block to your code without printing out the error.
Only change one thing at a time
When you are trying to fix a problem, avoid making a bunch of changes in a row. Instead, make a single change, and then test your bug. If that does not change anything, undo that change, and try something else.
Watch out for cached code
Often code can be cached, either by compilers or more commonly code loaded in a web browser. Make sure when you save the file that you aren’t still running the old version of the code. Usually a clean build or a clearing of the browser cache can resolve these issues.
Save your file
This is a rookie mistake, but I’ll mention it here for completeness. Make sure you have saved the code when you are trying to test it.
A note on auto saving: Some editors allow you to autosave. This combined with a framework or tool which auto reloads or auto compiles your code on save can cause spurious error messages. For example if you’ve only partially typed in some code and your editor decides to auto save, you might see an error because you have incomplete code. You’ll then need to be able to separate the actual errors from these spurious errors.