Beyond Console Debugging Tricks

Daniel Reis
OutSystems Experts
Published in
5 min readJul 1, 2016

--

Note from Editor: Daniel was very focused finding stuff to nitpick when Rita Marques Ferreira — editor of People Behind the Keyboard — snatched this picture. Thank you, Rita!

I don’t consider myself a nitpicker. That’s only true, and it’s all fine and dandy… until I find a console.log() that someone forgot to remove from the JavaScript code. And if we’re talking about debugger statements… all hell breaks loose! People I have worked with already know how much that bugs me (pun intended).

Sure, I had a few slips of the mind in the past. Who hasn’t? I learned quickly, though. Using those statements should be a last resource, especially when you are working with big teams. It’s disrespectful to your teammates to leave them in the code!

So that is why I started avoiding console.log() like the plague, and I can’t remember the last time I used a debugger statement. It’s been years now! I saw the light!

My experience at OutSystems, while meeting with clients and interacting with other developers, has shown me that people will do some crazy stuff for the sake of debugging. Some of this stuff is so out there and time consuming, that I can’t even understand their reasoning.

Instead of investing a little time, researching better ways and finding the right tools for the job, some people find extremely complicated schemes that end up not helping at all.

Inspired by those people and the inexplicable juggling I saw them doing while trying to debug stuff, I collected some of the most common examples I can present as proper alternatives for that process. With these simple examples you will learn how to avoid the wrath of your colleagues. You know, the prickly ones that get extremely bugged when you leave those debuggers on that JavaScript file.

Console Methods

When you need to accelerate your debugging like a boss, Console API is the solution. Here are a few examples of how you can streamline your debugging, big time.

Print a Stack Trace

One of the most regular problems I found was that people got lost when tracing events, and finding out where a function was called from.

I present thee console.trace()! With this simple method you can trace your call, know exactly where it starts and trace its lifecycle.

In this example, I added a breakpoint to insert console.trace() within the RangeSliderObject. When the RangeSlider button was triggered, the trace was printed to the Console.

Display Object as Table Data

This one’s a personal favorite. With a simple console.table() you can get a friendly tabular output of your Object or Array, displayed in your console. Say goodbye to the not-practical-at-all click on Object you need to check to browse in the console.

In the Console, wrap your object inside console.table() and you will have a tabular output. You can also add a breakpoint in the browser, for the file you need to check, and add the console.table() there. The output will be printed to the Console.

Set a Timer

What do you do when you need to know how long a piece of code takes to run? I’ve seen some strange sorcery out there for this one, but the solution is actually quite unmagical. All you need to do is start a timer with console.time() and then stop it, when needed, with console.timeEnd().

In this example, I added a test console.time(), ran some code, and stopped the test process with console.timeEnd().

Check the CPU Consumption Values

Check the CPU profile and analyze the time consumed in each run with the very handy console.profile(). This will give you an idea of what’s more expensive in your JavaScript code.

In the Console, just add the console.profile() to start, and console.profileEnd() to finish. After that, you can check the results in the browser’s Profiles tab.

Check Object Properties

If you need a JavaScript representation of an Object, you can use console.dir(). That will give you a list of properties for that Object.

Once again, it’s all done in the Console, pretty much like the console.trace() example.

3 Extra Tips

Here are 3 extra tips that you may find useful for an easy debugging.

Quickly Find a Function to Debug

Sometimes, you want to quickly debug a function, and you have a lot of resources. Ctrl-Shift+f does not find you exactly what you want. The script will stop as soon as it reaches the function you wrapped within debug().

In this example, I wrapped the buttonGroup function with the debug method in the Console. The code stopped when it was triggered — in this case, by calling the function in the Console.

Monitor the Arguments of a Function

Imagine you simply want to monitor the arguments passed into a specific function, but you don’t want messy output to crowd your code. That’s when you use monitor() to fetch those precious, precious values.

In this example, I wrapped RangeSliderObject in monitor(), in the Console. The output was printed there after the function was triggered.

Access the Console Inside an iframe

I repeatedly saw people that wanted to access the console inside an iframe opening that very iframe in another tab. Sometimes they needed parent page context, so they had to manipulate some data in the console.

Going back and forth like this is impractical, but there’s a quick solution. You have a dropdown in the browser’s console tab, showing all the documents rendered by the browser, so you can switch easily:

This selection is also accessible from the Console tab.

These are just a few of the tricks we use daily to maintain a sane environment and appease the gods of code cleanliness, but keep your eyes peeled for more. We have a few more tips up our sleeves that we promise we’ll share with you, very soon!

Edit (7th July): About one week after publishing, I feel the need to add a little disclaimer: all the examples in this article were used directly in the browser. None of these ended up being added to the JavaScript file and deployed like that. I’m not aiming at replacing bad with somehow less bad.

The idea was to provide a simple alternative for the many (many!) cases I witnessed, out there in the field. You can see this as a statement in favor of having “Everything in its right place”.

Just don’t use the same console.log() for everything, study these alternative methods, avoid developing code in a JavasCript file in order to have an output with console.log().

As for the tone… Guys, it’s all in good fun. ;)

Daniel Reis | Mobile and Front-End Expert at OutSystems

Are you over console.log()? Let the world know: LinkedIn | Twitter | Facebook | Email

--

--