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

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

LrFIEQsO8MyJhwmLvB5Gb2TDaV9EYOW8gqfx
Credits to reddit

Below I will share some tips that have helped me in difficult moments.

The basic / well-known ones

Rubber duck debugging

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

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

Yet the duck 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. It might be totally off from the actual cause, 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 helpful on a future issue.

I could argue 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.

More on logging later.

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. Have a routine and an ‘end’ in your mind when using it.

The less well-known ones

console.table

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

-Ek-xKZX9Bw75cKgaNGvNRQHrmWgqoQ46XKb
console.table at its best

See what a nice overview you can gain from the layout? I highly encourage you to use it 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 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’s 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 a 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.

More reading

Apart from the links cited inside the main text of the article, here are some more things I think are worth reading about the topic of debugging:

Originally published on my blog.