Stepping up your javascript debugging skills

#tipsandtricks #problemsolving #javascript #debugging

Almost all software developers, who have written even a few lines of code for the Web, had at least a quick glance at javascript in their life, which is one of the most in-demand programming languages currently.

Some people love it, some hate it. Regardless of your view, if you use it, you will need to debug it eventually.

Below I will share some tips that help me in those difficult moments.

The basic / known ones

Rubber duck debugging, is a method where you explain your problem to anyone or anything(it doesn’t have to be a human) and the solution, magically stops playing with your goodwill and appears to you.

Given the ‘duck’ has no knowledge of your project and you explain everything, questioning your assumptions at the same time, you suddenly have an enlightenment like ‘Oh dear, it was in front of me, thanks bro, sorry for the interruption’.

The bro was silent all this time and that’s the magic part. :)

The good ol’ logging

When you have an issue to debug, you usually have a vague hypothesis of what might be wrong(which is totally off from the actual cause usually, but this is another story). If you start putting logs in places where the error might occur, you may get to the point fast.

Even if you don’t, don’t remove the logs you added, as they might prove themselves great help on a future issue.

I could argue on why you should never reach this point, to add debug logs, as the logs should be there as part of the initial development, but Erik Hazard has already done the job.

Breaking the points

A debugger is a great tool in your arsenal and a great help, if you know how to use it. That means,

First understand the problem
Then make a couple of hypotheses about the root cause(and not the symptom)
Set the appropriate breakpoints to verify or disprove them.

In javascript, you can either set in the browser’s dev tool or use the debugger keyword in the code to force pausing the execution.

So don’t just put random breakpoints here and there, but please have a routine and an ‘end’ in your mind when using it.

The less know ones

A few lines above we spoke about the importance of logging. The command we usually use is console.log('text'). But what if the output is more complex? Yes, console.log handles arrays too. And objects.

But what if I told you that you could spot the error faster because of some…beautification? That would be console.table method and is demonstrated below

See how nice overview you can gain from the layout? I highly encourage you to use it more and more, especially with iterables.

Break on events instead of lines

Let’s imagine the following scenario. A DOM element is changing intermittently and with wrong values, and you have no clue why. Which of the 29 functions that mutate it, is being naughty? (Side note: Mutating is bad usually, but this is a topic for another blog post)

Use the DOM change breakpoints. Every time the element is mutated, a stack track will be shown. Just like if you have put the correct breakpoints. You can find more details here

Profiling

If the bug you are working on is not performance oriented, maybe this is an overkill. But I still have to mention it(well, it may be a performance issue after all :) ). In Chrome and Firefox you can use the profiler built-in functionality to spot a bottleneck or just…see the functions that are executed. Boom :). Overengineering at its best. Please use this feature wisely. Killing a fly with bazooka can have some weird side effects.

Conclusion

Thank you for reading this article. I hope you enjoyed it and learned something today. As always, I highly encourage to share your magic techniques in the comments.