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.
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.
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
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.
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.
Apart from the links quoted inside the main text of the article here are some more stuff I think are worth reading about the topic of debugging
- Node debugging tutorial
- John Sonmez’s debugging guide
- Debug it
- Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
- Chrome debug tools
- Firefox debug tools
- ‘JSparty’ podcast and especially episode 30 from where I got inspired about this post and learned about
Originally published at perigk.github.io
Top comments (2)
console.tableis a nice tip. Thanks!
Glad I helped, thank you :)