Adding console.log() to our code is probably one of the most common practice among developers. However, I have spent a lot of time in my life to persuade beginners (and sometimes proficient coders) to stop using it for debugging JavaScript. Here’s why.
First, I must admit that I’m still doing console.log() statements in my code — old habits die hard. I’m not alone: Around 75% of Node.js developers report using it (in 2016, https://www.clarkio.com/2017/04/25/debugging-in-nodejs/) for finding errors in their applications.
In a couple of situations it is either the simplest thing to do because you know exactly what and where to log information, or it’s the only thing to do because you are in constrained production/embedded environments with no other tool. However, this not an excuse to make the exception lead your daily practice. Indeed, as a general rule, console.log() is painful and prone to errors — as you will see hereafter. There are much more sophisticated solutions available.
Missing Contextual Information
console.log() forces you to consciously select which information to be logged prior to debugging. And what you display in the first place isn’t sufficient or even completely irrelevant because you usually don’t yet have any idea of what’s going on.
Every time you launch your app, you go a step further — whether it be realizing you’re still not logging the right information at the right time or wasting hours changing your statements again and again to display new information and hide irrelevant info.
Counterattack with a debug tool:
- Display/watch any JS variable inline while debugging (function arguments, local variables, global variables, etc.)
- Explore the call stack to get the complete context in which your problem appear
Too Much Information
Algorithms are usually designed to automate a large number of small tasks — loops and recursion being fundamental building blocks for this. Along with console.log(), it results in a large number of lines displayed in front of you, so you may have a hard time coming to find the right information.
Counterattack with a debug tool:
- Create conditional breakpoints[https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints#conditional-loc] to pause the execution when a specific condition is met so you can take time to analyse what’s going on
- Watch custom JS expressionshttps://developers.google.com/web/tools/chrome-devtools/javascript/reference#watch so you don’t waste time deriving the same expression at each step of a loop
- Create a debug log classification[https://blog.risingstack.com/node-js-logging-tutorial/] in addition to your standard application log in order to activate debug messages on-demand for the domain of interest (e.g., file, service, class, etc.).
Untrustworthy Information
You cannot always trust information reported by console.log() because there is simply no standardized behavior about it. You don’t really know what happens under the hood.
Most of the time, calling console.log() when the console is not yet active only results in a reference to the object being queued[https://stackoverflow.com/questions/23392111/console-log-async-or-sync], not the output the console will contain.
As a workaround, you’ll need to either clone the information or serialize snapshots of it. The rendering happens asynchronouslyhttps://stackoverflow.com/questions/23392111/console-log-async-or-sync alongside future interactions with the logged objects (e.g., expanding object properties in the browser console).
Counterattack with a debug tool:
Asynchronous stack traceshttp://mrbool.com/how-to-debug-asynchronous-javascript-with-chrome-devtools/33573 allow you to inspect function calls beyond the current event loop, just like a context-aware travel in time to the originators of your asynchronous callbacks
Altered Code Behavior
The standard way to debug asynchronous code is to console log 1, 2, 3, 4, etc. (i.e., all executed steps before the output you’re expecting until you get the right order).
As a consequence, you modify the code and thus the way it runs, which can lead to really hard-to-track, unsteady behaviors. After you finish debugging, you also have to remember to delete all the stray console logs in your code.
Counterattack with a debug tool:
- When it comes time to really understanding the flow of an application, going step by step[https://developers.google.com/web/tools/chrome-devtools/javascript/reference#stepping] is mandatory
- When it comes time to really understand the timing of asynchronous callbacks, breakpoints[https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints] are your best friends (select the type that best suits your problem)
The Debugging Toolkit for JavaScript
To help you debug a full stack JS application, you actually really need a few tools:
- Chrome DevTools[https://developers.google.com/web/tools/chrome-devtools/] now supports Node.js debugging[https://medium.com/the-node-js-collection/debugging-node-js-with-google-chrome-4965b5f910f4] in addition to JS code running in a local or remote browserhttps://developers.google.com/web/tools/chrome-devtools/remote-debugging/
- Node.js debug[https://github.com/visionmedia/debug] module
And if you believe you can’t use the debugger when running your tests, consider reading this article[https://peterlyons.com/js-debug/] and other similar resources you might easily find on the internet.
There is probably no one-size-fits-all solution anyway, so if I have not convinced you and you don’t still want to use the debugger as your main debug tool, I would suggest you read this article[https://medium.com/@shanebdavis/debuggers-are-broken-become-a-console-log-samurai-f352accd9ef6] to make your logging smarter. One can also mention third-party modules like winston[https://github.com/winstonjs/winston] or loglevel[https://github.com/pimterry/loglevel] for JavaScript as fairly good customisable loggers, but on my side I prefer to use them for production-grade logs only (e.g., information, warnings, errors, etc.). Others modules like debug[https://github.com/visionmedia/debug] are more appropriate for debug/trace logs.
Thank you for your watching!
Top comments (3)
Be better at the both debugger and logging, not just one of those. If nodejs would have multi threading, you should know that console.log would be your friend, because step by step debugger would be broken at all. That's the experience in Java and C# world. Logging may provide wrong context, that's just because you provide no context to yourself, so don't blame console.log.
Wow, thanks. I always thought console.log() can sometimes be the easy way out. Great article on debugging.
I ve been looking For this