Skip to content

Instantly share code, notes, and snippets.

@bartdorsey
Last active July 23, 2024 19:35
Show Gist options
  • Save bartdorsey/df9a43081f1b66996daf0b6d13a97b11 to your computer and use it in GitHub Desktop.
Save bartdorsey/df9a43081f1b66996daf0b6d13a97b11 to your computer and use it in GitHub Desktop.
How to Debug Code

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment