A couple of primates taking a selfie.

Get Comfortable with Your Debugger, Now

July 2nd, 2019
min read

In the previous post Stop Using Print and Die Statements, I talked about talked about the power of a debugger. Let’s get comfortable using this tool crafted by the Gods, and handed down to us meager programmers. Quick preface, all debuggers are the same in essence. Some are easier to set up and use (Javascript, Ruby) others are a horrendous pain in the ass. Here’s to lookin’ at you PHP. However, regardless of which language you use the features are transferable. I chose Javascript due to it’s popularity, and ease of access.

All examples are going to be shown utilizing the Firefox browsers debugger, which all JS devs have readily available.

Setup

A recursive Javascript function A recursive Javascript function
Recursive Function to Repeat a String.

This is our method in which we are going to debug. It is a little over the top and not something that I would write in production. However, I chose recursion because people find the topic difficult, and a debugger greatly clarifies it’s usage. I also added in extra methods so we can display what the debugger is capable of.

Quick explanation, this code takes in a string and an integer. The function will call itself x amount of times. The job of the function is concatenate the string on itself. So say we have repeatString(‘test’, 2), the return value is testtest. However, if the number passed in is a negative number, we just return an empty string. For further reference to the supplied problem take a look at freeCodeCamp

How to Start a Debugger

All that we need to do to get started in Javascript is throw in the debugger keyword. You can place this at any point of execution. The next step is to open your developer tools. The debugger is skipped when the tools are not present.

A recursive JS function with a debugger keyword. A recursive JS function with a debugger keyword.
The above code, with the debugger keyword.

Execution Pausing

If you take away nothing more from this, at least see the power of pausing mid execution. Just seeing what is available to you as a dev can help when you are stuck.

The Firefox debugger paused during execution with arrows pointing to three main areas of the debugger. The Firefox debugger paused during execution with arrows pointing to three main areas of the debugger.
The debugger in all it’s glory, with key areas pointed out.

Let’s start from the top arrow and go down.

  • Expresses why the execution was paused. – Note that this will change if it has been paused on a break point
  • Shows the call stack. – Get comfortable here.
  • Shows the methods, and variables available at current scope.

This info alone can show you so much. The scope area shows the value of every available in your current execution scope. Just seeing what data is currently firing allows you to validate that what you expect, is happening. Based on experience, it can cause great headache too. Why in f- is that variable 4 when it should be the string “q”?

Use Caution

In certain editors, this data can be updated live. Which effects the rest of your execution. Be cautious because you can cause adverse side effects that can throw you deeper in the weeds.

Breakpoints

The Firefox debugger with arrows highlighting breakpoints. The Firefox debugger with arrows highlighting breakpoints.
Breakpoints

Think of a breakpoint like a stop sign. You are telling your debugger that you want it to stop executing when it hits these spots. An amazing feature with our debugging tool, is you can hop into your code from the browser using the debugging tool, and click the line number. This effectively is the same thing as using the debugger keyword. You signal to the browser that you want it to stop at this line. I do find that most of the time I use the debugger keyword, but upon a massive debugging session, I will use breakpoints constantly. You can skip over code that you know works, and jump to various points that you are unsure of. Breakpoints are very powerful and can span many many files.

Step Into

The step into command in the Firefox debugger. The step into command in the Firefox debugger.
The Step Into Command

My most used command for a debugger is the step into command. This allows you to jump into the next method that is called. When you step into a method, this updates your scope with the data available.

Step Over

The step over command in the Firefox debugger. The step over command in the Firefox debugger.
The Step Over Command

This does what it sounds like, it steps over the current line, executing anything that happens on the previous line where it was paused. So you can skip methods that you know are returning the proper data. Or simply skip over declaring variables.

Step Out

The step out command in the Firefox debugger. The step out command in the Firefox debugger.
The Step Out Command

This command steps you outside of the current function, and jumps down to the next line of the parent that called the function. So in our example, say I step into the numLessThanZero function, I can step out of that method and it will take me to the next line in the parent that called it. In this case, it is our repeatString function. This is not one that I personally use all the time, but it comes in handy to check one off methods where I am not sure of what it is supposed to do.

Resume Command

The resume command in the Firefox debugger. The resume command in the Firefox debugger.
The Resume Command

I love this command. It is simple, yet surprisingly powerful. Resume allows you to resume execution, surprise surprise. However, if you have another endpoint selected, regardless of file, it will continue execution up until that breakpoint.

I use this so often to check a variable in one class, then hop over to a different one just to check on data. This affords confidence in our code, knowing that what we wrote, does what we think. Or not. ?

Saddle Up and Get Comfortable

If you have never used a debugger, please don’t be scared of this tool. You will only thank yourself when you realize how much power and scrutiny you have over your code. Yes you can use a console.log to determine what a certain value is, but what about the global values that you don’t think of? How is that affecting your current execution? Or maybe that method we were sure was returning an int, is instead returning a string? (Here’s to looking at you loosely typed languages ?). The power comes in the form of knowledge. And with knowledge comes confidence. Show your seniors that what they wrote is broken.

If you would like further proof of a debuggers power, listen to the Syntax podcast on debugging. You can hear a senior (10 plus year) dev’s mind explode when he realizes the power that he has been missing out on. That alone should convince you.

Wrapping Up

I know that I focus entirely on JS in this post. I personally find that silly considering I don’t write much Javascript. I want to end this by saying if you are interested in seeing the debugger in action with a more “server” side language, I will be happy to show the setup necessary. PHP is a bit of a bitch to get up and running. I promise, it is worth it.

Let me know what you think of the debugger in the comments, and please give me tips that I have not thought of.

Your info will only be used for comments.

Leave a Reply

Your email address will not be published. Required fields are marked *

 

Sam Ringleman

Software Engineer && Husband && Father

I suck at typing.

I drink way too much coffee.

Always loves a good dad joke.