All examples are going to be shown utilizing the Firefox browsers debugger, which all JS devs have readily available.
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
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.
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”?
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.
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.
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.
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.
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.
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.
Let me know what you think of the debugger in the comments, and please give me tips that I have not thought of.