Advanced Debugging Techniques in JavaScript – Part 1

This was originally published in the Keyhole Software blog on 1/6/2014.

Introduction

I was a terrible debugger when I first started programming. I could tell an issue was happening, but it always took me a long time to track down where and why it was happening. Even in a strongly-typed language like C++, it took me hours to find simple bugs in my code.

Debugging is one of the hardest parts of being a programmer. There are as many classes and books on programming as stars in the sky, but next to nothing on formal debugging. When an issue occurs, it could be in code you’ve written, code someone else has written, code another company has written, an issue in the user’s browser, a network hiccup, or any other number of issues. Figuring out where and why something is broken takes time even for the best programmers.

I’ve been writing code for a long time, and have picked up some tricks along the way. In this blog series, I’ll go over some strategies I use to diagnose and fix bugs. Some techniques and strategies I discuss are specific to JavaScript while others can be applied to any programming language.

Validating Assumptions

All of the techniques I will discuss are different flavors of the same idea: validate your assumptions.

As I said before, I was a terrible debugger when I first started programming. It was in my third programming class in high school that I started to really ask myself why debugging was so hard. I made a conscious effort to analyze and dissect the things I was doing to fix my bugs. A pattern emerged after a while. I found that I was spending much more time than I needed to on peripheral issues than trying to address the issue itself. My effectiveness increased tremendously when I would first identify my assumptions, then formulate how they could be validated.

The best way to focus on the issue itself is to validate your assumptions. Let's say a user has reported that clicking an Add button isn’t bringing up the Add form. A list of assumptions immediately comes to mind:

1. A controller bound the Add button’s click event to a method.
2. The method will open up the Add form when executed.
3. The Add form will open up correctly when told to do so.

Each assumption should then be validated. If it turns out the assumption is valid, then the bug more than likely isn’t there. If it is invalid, then the bug is more than likely there. Some ways to validate the assumption are:

1. Ensure that the method is actually getting called on click.
2. Make sure the click event is spelled correctly.
3. Check that the event is bound to the correct method.
4. Test other click listeners to be sure they’re getting called.
5. Is the Add form able to actually open?

Debugging an Enterprise-level application can be a ting task. There are so many different files and classes that it can be overwhelming to debug something like the issue above. The best part about validating assumptions is that it is actionable and concise. It limits the scope to just what is relevant, and provides real tests that can be ran to identify a problem quickly. Its effectiveness is only limited to how well the assumptions are defined, and how direct the validations are.

There’s no real trick to figuring out what the assumptions are. It’s something that takes time and practice. There are, however, several different techniques I use to validate my assumptions.

Binary Search

Most people, even if they aren’t programmers, use binary searches on a regular basis. When someone guesses a number and is given feedback of “higher” or “lower,” they are using a binary search to narrow down the solution. The idea behind a binary search is simple: split a data set into two, and find which half contains what you’re looking for.

The same concept can be applied to debugging. Assume I have a really long, complicated method that produces a bug. I need to find out where in the method the bug starts occurring. Rather than checking each and every line, I comment out the second half of the method. If the bug no longer happens, then I know it must be caused by something I commented out. I then comment out the first half, uncomment out the second half, and comment out the last fourth. If it still happens, I know the issue is in the beginning of the second half. This process can be repeated until the culprit line or expression is found. Imagine how much time would have been wasted had the first half been checked line by line. It may have yielded some results, but since the bug was in the second half, there’s no reason to really consider the first.

The binary search technique is one that can be applied to any language. One disadvantage is that it makes the naive assumption that all methods are modular enough to run one section and produce the same result. There are often cases where a variable in the first half is used in the second half, so completely commenting out the first half isn’t an option. Binary search still allows large chunks of code to be ignored to find the root cause.

debugger Statement

Setting breakpoints to get the current call stack and local/global variable is a cornerstone to any debugging utility. JavaScript debuggers do allow breakpoints to be set when inspecting code. Most people, however, don’t know about the debugger statement.

The debugger statement allows you to define breakpoints as part of the code itself. If the same line needed to be inspected in multiple different browsers, it’s easier to put a debugger statement in the code than try to set the breakpoint in each individual developer tools.

To put a debugger statement in JavaScript code, simply do:

debugger;

I use debugger statements for a wide variety of uses. If I’m working on coding and need to setup stub methods to fill in later, I’ll add a debugger statement to remind myself to fill it in. I also don’t put white space to the left of those kind of debugging lines to make it easy to spot and correct before I check my code in to source control.

I’ve noted several times that the debugger statement is a statement, not an expression. This is because I’ve often seen people write:

if (this.someMethod() && this.someOtherMethod() && debugger && this.someOtherOtherMethod())

They want to see the call stack after someOtherMethod is executed, but don’t want to step through each previous method. The line above is invalid JavaScript syntax, and will throw a run-time exception. The valid version of the code uses an automatically executed closure:

if (this.someMethod() && this.someOtherMethod() && (function(){debugger;})() && 
this.someOtherOtherMethod())

It looks funky to non-JavaScript programmers, but it works.

I prefer debugger statements to setting breakpoints in the browser’s developer tools. If you set a breakpoint in a file in Chrome and it is loaded asynchronously, it will throw a breakpoint at the end of the file once it is loaded. This gets very annoying if you’ve put breakpoints in multiple files. Debugger statements don’t suffer this behavior. They also make it easier to compare behavior in two browsers at the same time.

Overview

In this blog, I’ve gone over the paradigm I use when debugging. I also discussed binary searching, which can be used in any language. The debugger statement allows for quicker debugging between browsers. In the next blog, I will go over top-down, bottom-up, and event listener breakpoints. These are slightly more advanced than the previous techniques, but are critical to effectively debugging complex JavaScript application.

The post Advanced Debugging Techniques in JavaScript – Part 1 appeared first on Zach Gardner's Blog.