Back to Basics: Debugging Code

By Taryn Engmark

Associate Editor

Embedded Computing Design

We all know the suffering that is the debugging process. The hours spent banging your head against the desk… the sleepless nights spent screaming into the void over three lines of code… the moment when you realize that you sacrificed your firstborn child just to find out that you were missing a single semicolon. Coding is sometimes pain.

Welcome to Back to Basics, a series where we’re going to be reviewing basic engineering concepts that may require a more complex explanation than a quick Google search could provide.

Debugging is the process that we coders use to work through that pain. Code sometimes has bugs; this is a fact of life. As software designers and engineers, our job is to find those bugs and make the code a working whole again. But there are a few simple tips to make that process as painless as possible.

Only Entomologists Like Bugs

The first thing to remember is the unfortunate fact that computers will always do exactly what they’re told. An even more unfortunate fact is that any bug-related problems in your code are your fault.

With that knowledge in hand, the process of debugging becomes that of using the scientific method.

Observation: Something is wrong: you have a bug. For example, your code is returning an ArrayIndexOutOfBounds exception and crashing.
Hypothesis: Maybe there’s a problem with how the arrays are being manipulated. The next step is to make a guess about where that problem exists.
Test: Check your hypothesis to see if it’s correct and adjust accordingly. For this step, make sure not to change more than one thing at a time. If you make multiple changes, there’s no way to tell what you may or may not be fixing or breaking.

The first of these three steps is normally very simple. You expect the code to do something, and it doesn’t. Hypothesizing and testing takes much more time and effort. To streamline the process, here are a few principles to follow.

You Are Your Own Exterminator

Check Your Code Often: This is simple to say, but very important. It’s easiest to find bugs if you know roughly when in the coding process they showed up. Test each section of your code as you write it, even if that means writing extra code just for testing. It’s incredibly valuable knowing that each section of your code works before moving on to the next.

If You Can, Use the Debugger: Most IDEs have a built-in debugger — a tool that allows you to go through your code line by line and see exactly what value is stored in each variable at any point in your code. Using a debugger helps you find exactly where in time things went sideways and correct the problem.

Check the Syntax: If you’re seeing red squiggly lines, it’s very likely your code won’t work. Finding syntax errors is usually pretty simple, but sometimes they can get lost in the flow. Double and triple check your code!

Semantics Antics: Semantics errors are much harder to find. Missing semicolons, while syntactically correct, can ruin entire blocks of code. Check whether each line of code does what you think it does (the debugger can help immensely with this step).

When writing code, set the expectation that debugging will occupy about 80 percent of your development time. While these tips help, there’s nothing that makes the process seamless. The essential thing is to look at debugging as a scientific process. Be methodical, check your work, and don’t change things if you’re unsure.

While debugging is a crucial step in the code development process, it also goes hand-in-hand with our next step: testing your finished product and conducting quality assurance assessments to ensure all is operating as it’s supposed to. But until then, enjoy your pest control.

Click here to read the first installment of Back to Basics: Ideation & Requirements

Click here to read the second installment of Back to Basics: Development Stack

Click here to read the third installment of Back to Basics: Configuring the Development Environment

Click here to read the fourth installment of Back to Basics: Pseudo-coding

Click here to read the fifth installment of Back to Basics: Coding and Commenting