Stop Overusing Console.log in JavaScript
The web browser console gives us more options than just the console.log()
OK, I admit it, and I’m not very a fan of it. Mostly I use console.log() for troubleshooting, checking that the arguments of a function get the correct values or that a function returns what I expect it to do. Sometimes I take shortcuts using the built-in browser method console.log() to clarify the result of some piece of code. On infrequent occasions, instead of rendering a ReactJS-component to the Graphical User Interface (GUI), I may print the component to the console to examine its properties.
I’ve seen many developers are using the web console in similar ways as I do. We developers should stop overusing the console.log() and instead draw advantages from what we can do with the web console than just reading simple logs.
I want to discuss some common issues and bad habits that we usually do and some solutions for using the console better.
Issues and bad habits
How often do we think about why we use the console.log() method, and in what contexts? Is it just purely automatic that we use it? Why do we always have to do all this logging, especially with console.log()?
In many of these situations, instead of reading and understanding the code, we make guesses and try to help ourselves by logging stuff to the console. All this time we spend on logging can be very time-consuming (sometimes it can even make us even more confused), and we probably “learn” slower.
Unnecessary logging = less confidence
An unnecessary amount of logging to the console makes us less confident. Developers often log to the console in many parts of the code — especially if functions are deeply chained — to “test” our code is reliable.
Using the console for “confirmation”
In far too many cases, we also accept that when logging something to the console, we get an indication that “everything works fine.” We can prevent building agents or scripts from breaking if we read and understand the code thoroughly instead of relying on the “confirmation” that the console may give us.
We often use this “confirmation” to check whether something is wrong or not, whether an object is undefined or an array has a length. I would say that “confirmation” is OK when our code breaks, and there are no other options.
Debugging is time-consuming
Debugging in the console may be time-consuming. Sometimes we can sit for days logging things to the console, taking away the focus on understanding how the code “actually” works and other options that we could have tried instead of just logging stuff.
Logs may end up in production
Logging to the console can be deployed in production, which is not always that great — especially if we log critical information that should not be available to “everyone” on the web.
How we should use the web console
What is essential to know is that the console also is a REPL. That means we can interact with JavaScript on the page we’re inspecting. Using the REPL is a great way to play with and learn JavaScript.
Useful console methods
The overusedconsole.log() is just one of many methods we may call on the console object. console.error(), console.info(), and console.warn() may be better in cases where we will separate different states of messages. And, to get a better representation of our data in the console we can use methods like console.group() and console.table().
console.error(): Prints an error message to the console, where the printed content will have a red colour. Most browsers also displays an error icon beside the console message.
console.error(‘Something is wrong’)
console.warn(): Prints a warning message to the console, where the printed content will have a yellow color. Most browser also displays an warning icon beside the console message.
console.warn(‘Heads up! This is a warning’)
console.group(): Prints a group of console methods executed within the group. Such logging is usable when we need to do more than a single log in different files which is not related. We can also open and close groups in the console.
console.group(‘feature’)
console.warn(‘Heads up! This is a warning’)
console.error(‘Something is wrong’)
console.groupEnd(‘feature’)
console.table(): Prints a table representation of the data provided. The method accepts objects and arrays.
console.table([{ a: 1, b: 2 }])
Some final words
It’s not uncommon [for JavaScript beginners and professionals] to just print strings that say “works” or “done” or something similar and then use them to “confirm” that our code works as expected. I’ve seen far too many uses of console.log() in different places in a codebase simultaneously during a pair programming session.
Browser consoles are great tools, and we should use the great utils they provide to our benefit; testing JavaScript methods or extracts, playing with Document Object Model (DOM) or objects in our code. We can do much more with the console than log simple strings, numbers, or lengths on a list.
We should focus on understanding the underlying code and using the console for its benefits and not as a tool for confirmation; then, we will learn faster, become more confident and write better code in the future.
Thanks for reading
Code foh shizzle
