Unless you’re goddess, please debug

You are not debuggers, you are programmers.

To celebrate the new debugging option Chrom added to the developer tool at version 70, And as a response to someone brilliant, who did not use some of the basic debugging options, this time I’ll list the different ‘native’ ways we have for debugging our JavaScript code. The weird quote will be explained at the end.

A. What you see it what you get.

From the ancient times, until this day, the most basic way to see the value of variables is to print them on the screen. Hopefully, the developer had a basic common sense to find better ways, and still, if you are doing so, be careful that the code will not slip into production. And yes, I had worked with someone that had done that or even worse, displayed a variable on the middle of the screen of thousand users, just because he was too lazy to find a better way. Don’t, just don’t!

...
...
document.getElementById("theMainElementOnThePage").innerHTML = usersStolenId;
...

Naive, but still useful on Jsfiddle playgrounds or while learning how the VUW/NG HTML tags works.

B. No one is looking behind the fridge

One more technique I had seen, that is dangerous than the first, is to write the values inside hidden elements on the page. The programmer believes his work is so boring, that he has confidence no one will look at the source code. That’s how I saw once on a website something like this:

<span hidden>
    User test group = 2<br>
    User discount = 30<br>
    If you see this, don't tell my boss
</span>

C. Let’s console ourselves 

Now we start going over the useful options. And the one probably mostly used is the console.log. Throwing values to the console, and watching the app as its running all around and trying to guess how we got from point a to b.

console.log(someValue);
console.table(toSeeValuesInATable)

There are plenty of useful logs that can provide important information about the code, and I’ll cover this on a different post. Here I’ll just mention one:

console.time('codeRuntime');
for(var i = 0;i<10000;i++){
   i = i;
}
console.timeEnd('codeRuntime');
//codeRuntime: 3.282958984375ms

But please, go back to your code and remove the logs, we both know you have forgotten some!

D. Simon says: freeze

Finally, we get to the real debugging: watching the code flow and how the values change at runtime. The most static way to stop the code is by placing the keyword “debugger”. Though on the next section we will point to the option to place breakpoints on the developer toolbar, this option is helpful for debugging dynamic code or code that’s loaded at runtime.

var dynamicCode = `
    var a = Math.random();
    if(a > 3){
        //we will never get here
    }
    debugger;
`;
eval(dynamicCode);

E. Code breakpoints

And this is the basic programmer tool, the bread and butter of every programmer.

If you are don’t feel comfortable with breakpoints, do yourself a favor, and stop whatever you are doing, stop even reading this boring page, and start playing with it: add, step into and step out of function, understand the “call stack”. After that, do it even more.

I’m serious, stop reading right now and go add some brakes to your code!

F. Other breakpoints

Just know they exist, you will probably forget them until one day you’ll get stuck and they will come with their superpowers and save your life.

• DOM change breakpoints
• XHR/Fetch breakpoints
• Event listener breakpoints
• Exception breakpoints
• Function breakpoints

Just so it won’t get boring, here is an example of the function breakpoints:

function stopEverythingAndAllowMeToSeeWhatsGoingOn(value) {
  return value;
}
...
...
...
// O, I found at runtime that I need to track use of this function:
debug(stopEverythingAndAllowMeToSeeWhatsGoingOn); 
...
...
...
stopEverythingAndAllowMeToSeeWhatsGoingOn(true);
////Kaboom, we will pause at the beginning of the function before getting here...

F. Conditional breakpoints

This is one of the less known but very useful tools. Let’s say you want to see why sometimes a function returns a wrong value. The problem is that you call the function more than once, and the error happens only once in a while. You can debug the function each and every time until you fall asleep. Or you can add a conditional breakpoint, and phase the function only when you need it.

G. Live Expressions

And here comes the new feature of Chrome v70. Easy option to see changes on a variable or expression above the console, without the need to click the refresh icon. Just use  Saruman eye above the console to role them all.

H. Dark IDE magic

This is pure dark magic: attaching the chrome process to the IDE. this provides the ability to add breakpoints in the IDE, like Visual Studio and .NET, Java and the other bigger brothers of JavaScript. Or the option to change the code on the developer toolbar, and see the files change on the IDE.

Final words

It’s a brief review of a huge topic, on an enormous topic. But I passed the word limit for the Prozac generation. Once my CEO had seen the developers debugging his code and got mad and yelled: “You are not debuggers, you are programmers”. Though he was right, we covered our screens until he left for his office at the mountain-top, and then we returned to the real programmer’s world.