DEV Community

Cover image for Hidden gems of debugging 💎
Amandeep Singh
Amandeep Singh

Posted on • Edited on

Hidden gems of debugging 💎

Anything that cuts some of your arduous task time is good for your productivity. Debugging is one of those strenuous tasks. Developers strive to write bug-free code, but we all know that it’s not easy. No one likes to see bugs in their code—those red color lines are not very appealing, right? Nonetheless, errors are good if you happen to catch them early. Debugging them properly will give you new learning and a feeling of satisfaction. There were countless moments when I learned a lot while debugging my own code and seeing how it could challenge my own concepts.

We all learn by making mistakes, and make mistakes again to learn more.

Enough of motivation. Let's get to business.

Today, I am going to share some of the tricks and tips you could use to supercharge your debugging skills. I've only tried these tricks in chrome dev tools (sorry FireFox users), but some of them are browser agnostic.

1. Using shorthand object property value notation in console.log

This is my favourite console.log trick and has to be on top of the list. You must have written torrents of console statements in your code base trying to figure out the value of a variable. The Convenience of use has made "console" the leader of the debugging championship 🏆. The golden line looks like this:

 console.log(a);
Enter fullscreen mode Exit fullscreen mode



This is awesome and you get to open up your console dev tool to see the value. But, as the number of lines grows, it becomes hard to trace the reference of that particular value.

 console.log(a); // prints 20
 console.log(b); // prints 30
 console.log(c); // prints 40
// Sorry what was the reference variable for '30'? I am kind of lost😕
Enter fullscreen mode Exit fullscreen mode

A very obvious solution to this would be to dump in some string representation along with your variable. Thanks to the versatile nature of console.

 console.log('a', a); // prints a 20
 console.log('b', b); // prints b 30
 console.log('c', c); // prints c 40
Enter fullscreen mode Exit fullscreen mode

But as I said, we need to cut time and write fewer lines to be more efficient and productive, right? So, the trick is to wrap your variable inside the curly '{}' braces. This is really not a trick but a language feature know as object property value shorthand notation. You can learn more about it here.

  // use object shorthand property value notation
  console.log({ a }); // prints { a: 20 };
  console.log({ b }); // prints { b: 30 };
Enter fullscreen mode Exit fullscreen mode

Doing so, will give you the reference variable along with its value. Less code more value.

Bonus: Use 'var' instead of 'const' or 'let' when declaring variables inside your chrome's console tab to avoid annoying Syntax Error. 'var' is your scratchpad buddy.

2. No more wrapping of curly braces for fat arrow functions

You must have used fat arrow function by now (if you haven't, you should start using it). They are short and precise and omit the requirement of the curly braces and return statement when writing your function definition.

   const foo = x => 2 * x; // how awesome is that 😊
Enter fullscreen mode Exit fullscreen mode

A popular use case would be inside the array utility callbacks (map, filter, reduce, etc)

   let arr = [1, 2, 3];
   let newArr = arr.map(el => el * el); // [1, 4, 9]
Enter fullscreen mode Exit fullscreen mode

Now, let say if you want to debug the map callback function, how would you go about printing the el value? A simple answer would be to refactor the callback and throw in some curly braces around and inject return statement.

 let arr = [1, 2, 3];

 // using curly braces and return statement
 let newArr = arr.map(el => {
  console.log({ el }); // prints {el: 1}, {el: 2}, {el: 3}
  return el * el;
});
Enter fullscreen mode Exit fullscreen mode

What! are you kidding me 🙈? This is not ideal. Not only it's time-consuming, but reverting back will consume more time too. A better solution is something like this:

   let arr = [1, 2, 3];

   // more concise and inline 🎉
   let newArr = arr.map(el => console.log({ el } ) ||  el * el);
Enter fullscreen mode Exit fullscreen mode

Whoa!! what was that? Don't worry, it's just JavaScript. I'll explain:

There are two things going on here:

  • console.log() always returns undefined which is a falsy value.
  • Given a statement like expr1 || expr2, Logical OR operator (||) returns expr1 if it can be converted to true; otherwise, returns expr2.

So, return value of console.log({ el }) was undefined and thus second expression el * el was executed. The beauty about this change is that you get to see the value inline. No debugger or cumbersome curly ceremony is required. A big win, right? 😊

This is very handy when you are a fan of functional programming and use a library like Ramda.

3. Add logpoints—less sprinkling of console.log in your code

The console.log has become an indispensable part of our debugging journey. We tend to sprinkle it everywhere in our code; it has become our first line of defense against bugs.
The problem is time consumption while cleaning up these logs statements. You can obviously go and find each console statement and remove them manually. But what if I say there's a better solution? Embrace new kid in the town—The logpoint.

Google has added this feature in Chrome 73. It allows you to add console statement in your source code straight from your dev tool.

Steps:

  • Open Sources section of your dev tool and locate your source code.
  • Write click on any of the line numbers you want to add your console statements.
  • A list of options will come up; select Add logpoint.
  • A Breakpoint editor will show up allowing you to enter the variable name. It's similar to how you write your expression inside console.log() function.
  • Enter a shorthand property notation trick I showed you above. Click outside the editor or hit Enter to save.
  • An orange badge will represent your Logpoint and you are all set.

Now, every time your script is executed, you will see the values being logged out at the console section of your dev tool. You can add multiple log points.

Action speaks louder than words:

alt text

Bonus: You can also use conditional breakpoint feature to insert a breakpoint when the condition evaluates to true.

4. Store and copying

Chrome dev tool is where I spend most of my time debugging. I use it as my JavaScript scratchpad. It has lots of in-built features at our disposal. One of the cool feature, that has been so helpful for me, is copying the variable value into my clipboard.

To copy any reference variable, for example, x, into your clipboard, just type copy(x) into the console tab and hit Enter. Chrome will copy that variable into your clipboard and you can paste it anywhere by using normal paste command.

The big benefit comes into picture when you are playing around with network response. Here you can combine this copy feature with another excellent feature called store as global variable.

Let's see that in action:

  • Open your Network tab and select a request from the list.
  • Open up the Preview section on your right.
  • Right-click the property name and select Store as a global variable.
  • The variable will be shown in your console tab, and you can use copy() function to have it in your clipboard.

Kill two birds with one stone.

alt text

Bonus: You can use 'Ctrl + f' to search for a particular string match over the entire response object in the preview section.

5. The Breakpoint for your network requests

Ideally, you should strive to keep your HTTP requests as minimum as possible while building your client. Not only it gives you a smooth performance but also helps to avoid bugs.

In one of our project at Insurance Company, we were building a data-driven UI. Every next question in the form was driven by the user's previous actions and was fetched subsequently over the wire.
We needed to analyse that when a particular kind of request was triggered, we could debug the request payload accurately. I ended up finding this awesome solution called XHR/fetch Breakpoints. It allowed me to put a conditional breakpoint on my fetch requests.

XHR Breakpoints allow you to put breakpoints on all of your network requests. But the real power is the ability to apply breakpoint via 'URL contains' section. You can throw in any keyword there and chrome will put a pause when it encounters the request URL containing the matching word. How awesome is that!!

Steps are:

  • Open Sources tab of your dev tool and on the right-side panel.
  • You should see XHR/fetch Breakpoint section below Breakpoints.
  • Hit + button and a Breakpoint editor should come up asking you to enter the keyword.
  • Enter your keyword and hit Enter.

alt text

6. Copying your request as cURL

This is handy when you want to trigger your request from a command line too like cmd or bash. You can also paste the copied link into your Postman app and it will fill up all the request headers for you. Very handy in visualising your request.

  • Open you Network tab inside your chrome dev tool.
  • Locate the request you want to copy and right-click to bring multiple options.
  • Hovering over the Copy options will show you a list of a different format you can copy your request as.
  • Select Copy as cURL and it will be saved into your clipboard.

alt text

7. Don't let go off your CSS changes—persist styling when refreshing

This tip is dedicated to our UI/Designers friends. We know that via Styles section of Elements tab, we can modify the CSS. But these changes don't persist when you refresh the page. If you wish to persist the modification you made to the existing stylesheet, you can do this via the following steps:

  • Open Sources tab and select Overrides.
  • Click Select folder for overrides and select a folder where you want to save your changes.
  • A permission dialogue would pop up asking for permission. Go ahead and allow.
  • Select your folder and you are all set to rock 'n' roll.

Now every time you make changes to your existing styles, they won't disappear even when you refresh the page.

Note: Adding new style changes won't persist though!.


Final thoughts

You can't change the fact that it's practically impossible to write a 100% bug-free code. Rather than slamming your head against your desk, let's adapt and develop our debugging skills. Believe me, you will learn a lot by exploring the root causes of your bugs.

If you liked the article, a few ❤️ will definitely make me smile 😀. Now, go and kill remove some bugs now 🐞.

Top comments (18)

Collapse
 
lostdesign profile image
André

Know another gem 💎 ? -> webgems.io

A site I made for exactly these things, i'd love if you'd send a PR to github.com/webgems/webgems to add this article to the resource list.

Great article!

Collapse
 
aman_singh profile image
Amandeep Singh

Thank you André for your comment. I will definitely look into this and will create a PR soon. 😀

Collapse
 
aman_singh profile image
Amandeep Singh • Edited

Thanks 👏 for sharing this beautiful 💎. Given you have an easy eslint rules set up (or don't mind writing /* eslint-disable-next-line*/, debugger statement can really help. I never tried editing source code directly but I think it will be fun. I have purposely created a code snippet (in VS code) which expands to the aforementioned statement with a debugger in next line. 🙂

// VS code user snippet
  "debugger with eslint-disable-next-line": {
    "prefix": "deb",
    "body": ["/* eslint-disable-next-line */", "debugger;"]
  }
Collapse
 
droidmakk profile image
Afroze Kabeer Khan. M

Copy & Logpoint 🆒. Can also see for arr.sort and arr.filter

Collapse
 
flexdinesh profile image
Dinesh Pandiyan • Edited

This is fantastic. Thanks Aman. XHR breakpoints is an eye-opener. It's also noteworthy mentioning the use case for console.group.

Collapse
 
aman_singh profile image
Amandeep Singh

Thank you, Dinesh. Glad to read that it was helpful. :)

Collapse
 
robincsamuel profile image
Robin C Samuel

This is awesome!! Thanks Aman :)

Collapse
 
aman_singh profile image
Amandeep Singh

Thank you, Robin. Glad that you liked it. 🙂

Collapse
 
bradtaniguchi profile image
Brad

Awesome article! Learned some new things :D

Collapse
 
aman_singh profile image
Amandeep Singh

Thanks, Brad. Happy that this article helped you learn new things. :)

Collapse
 
danivijay profile image
Dani Vijay

This is one of the best posts about debugging. Please do tips and tricks on JS.

Collapse
 
aman_singh profile image
Amandeep Singh

Thanks Vijay for your comment. Glad that you liked the post. I've written another article So you think you know JavaScript? mentioning some of the pitfalls. 🙂

Collapse
 
alexpaper profile image
alexpaper

Amazing! Lot to learn! Thanks!

Collapse
 
aman_singh profile image
Amandeep Singh

Thank you for your comment. Learning little things every day makes you big. :)

Collapse
 
ankurloriya profile image
Ankur Loriya

Thank you to share here.

Collapse
 
aman_singh profile image
Amandeep Singh

Thank you Ankur for reading 🙂

Collapse
 
aman_singh profile image
Amandeep Singh

Thank you, Erick for your lovely words and the suggestions. I will explore other browsers too and see if I can grab some good debugging techniques to extend it into a series. Appreciate 😀