Adding 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 is why. console.log() First, I must admit that I am still doing statements in my code, old habits die hard ! I am not alone, (in 2016) for finding errors in their applications. In a couple of situations it is either the to do, because you know exactly what and where to log information, or the to do, because you are in constrained production/embedded environments with no other tool. . Indeed, as a general rule, is painful and prone to errors as you will see hereafter — while much-sophisticated solutions are available. console.log() around ¾ of Node.js developers report using it simplest thing only thing However, this not an excuse to make the exception lead your daily practice console.log() Missing contextual information force you to which information to be logged . And what you display in a first place is not sufficient or even completely irrelevant, . Every time you launch your app you go a step further, realizing you are still not logging the right information at the right time, wasting hours changing your statements again and again to display new information and hide irrelevant one. console.log() consciously select prior debugging because you usually don’t yet have any idea of what’s going on : Counter-attack with a debug tool display/watch any JS variable (function arguments, local variables, global variables, etc.); inline while debugging explore the to get the complete context in which your problem appear. call stack 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 it results in a large number of lines displayed in front of you, i.e. a hard time coming to find the right information. console.log() : Counter-attack with a debug tool create to pause the execution when a specific condition is met so that you can take time to analyse what’s going on; conditional breakpoints watch (variables, conditions, etc.) so that you don’t waste time to derive the same expression at each step of a loop; custom JS expressions create a 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.). debug log classification Untrustworthy information You cannot always trust information reported by because there is simply about it. You don’t really know what happens under the hood. Most of the time calling when the console is not yet active only results in a to the object , not the output the console will contain. As a workaround you will need to either clone the information or serialize snapshots of it. The (being throttled to rate-limit updates), as future interactions with the logged objects like expanding object properties in the browser console. console.log() no standardized behavior console.log() reference being queued rendering happen asynchronously : Counter-attack with a debug tool (now the default in Chrome) 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. asynchronous stack traces 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. : Counter-attack with a debug tool when it comes time to really understand the flow of an application, is mandatory; step-by-step when it comes time to really understand the timing of asynchronous callbacks, are your best friends (select the type that best suits your problem). breakpoints The debugging toolkit for JavaScript To help you debug a full stack JS application you actually really need a few tools: , now it supports in addition to JS code running in a local or (i.e. on a mobile device); Chrome DevTools Node.js debugging remote browser Node.js module. debug One can mention or as fairly good customisable loggers but I prefer to use them for production grade logs (information, warnings, errors, etc.). winston loglevel And if you believe you cannot use the debugger when running your tests consider reading and other similar resources you might easily find on the internet. this article If you liked this article, hit the applause button below, share with your audience, follow me on Medium or read more for insights about: async/await in JavaScript , the Feathers framework , the raise and next step of Artificial Intelligence, the evolution of Computer Science , the goodness of unlearning and why software development should help you in life ?

Flow

Google

How to build a map print service in minutes

A common misconception about async/await in JavaScript

Meaningful spatial insights

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Please stop using console.log(), it’s broken…

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A common misconception about async/await in JavaScript

10 Useful Tips & Tricks That Will Help You Make the Most of Chrome Devtools

10 Tech Products Ideas [September 2017]

10 Must Have Chrome Extensions for a Web Developer

12 Best Chrome Extensions for Developers in 2023

A common misconception about async/await in JavaScript

10 Useful Tips & Tricks That Will Help You Make the Most of Chrome Devtools

10 Tech Products Ideas [September 2017]

10 Must Have Chrome Extensions for a Web Developer

12 Best Chrome Extensions for Developers in 2023

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps