Debugging Best Practices in JavaScript
By: John Au-Yeung
Tags: JavaScript, Programming, Web Development, Technology, Software Development

Photo by Kelly Sikkema on Unsplash

JavaScript is a very forgiving language. It’s easy to write code that runs but has issues in it.

In this article, we’ll look at how to make debugging JavaScript programs easier.

Debugging Aids

To fix issues that arise in our program, we can introduce debugging aids to our JavaScript program that works in the development version of our program.

In JavaScript, there’s the debugger statement, console methods, debuggers and the assert module.

The debugger statement pauses a JavaScript program so that we can inspect the values of variables.

console methods can log values of variables in the ways we like, including colors, in a table, and even styling.

Some editors and IDEs like Visual Studio Code also has a built-in debugger for JavaScript.

The assert Node.js module is also great for checking if assertions are met and throw errors if they aren’t met.

Also, logging also helps a lot with tracing sources of errors.

Introduce Debugging Aids Early

We should introduce them early so that we can use to look for error sources as much as possible.

Use Offensive Programming

We shouldn’t make ignoring errors easy. So we shouldn’t let developers bypass errors so that they can be checked out and fixed.

Also, we can make case statements or else blocks shut down our program so that we won’t miss error values that are encountered.

Error logs can also be emailed to developers so they’ll be looked at.

Error reporting tools can be used to check for errors that are raised in any environment.

Remove Debugging Aids

Before releasing our program to production, we got to remove debugging aids.

We can do that with environment variables that toggle them on and off depending on the environment.

Just make sure that the aids are on in development and off in production.

Use Debugging Stubs

We can also add code that only runs in a development environment so that they help debug our code easier.

Determining How Much Defensive Programming to Leave in Production Code

We may want to remove some error checking code when our code is released to a production environment.

There’re a few guidelines to help us determine if we want to remove it.

Leave in Code that Checks for Important Errors

If an error is too important to ignore, then we should check for them.

Code that checks for invalid inputs and things like that should be included anywhere so that we won’t have bad data saved.

We got to add checks to make sure that our outputs are correct.

Remove Code that Checks for Trivial Errors

If there’s code that checks for errors that don’t many consequences, then we can remove them.

We can use version control, environment variables, etc. to toggle them on and off.

Remove Code that Results in Hard Crashes

Hard crashes don’t provide users with a good experience. Therefore, we should remove them.

We should handle them better so that it’s handled gracefully rather than crash our program.

Leave in Code that Helps the Program Crash Gracefully

The corollary of the previous point is that we should leave in code that handles errors gracefully.

They handle errors in a way that users wouldn’t perceive as a bad experience, so we can keep those in.

Log Errors for Our Technical Support Personnel

Logging is important since we’ll run into production issues eventually.

We make sure that we have logs that we can check to trace errors back to their original source.

Morgan is a good logger for Node.js apps.

Make Sure that the Error Messages we Leave in are Friendly

Cryptic error messages are bad.

We should make sure that they’re useful so that we can use them to fix the error that we encounter.

Also, we can add a contact phone or email for users to contact them for help.

Conclusion

We should have aids to help us debug in the development environment so that we can use it to troubleshoot.

Also, we can take out some error handling code that handle trivial errors or that if they cause a bad user experience.

Logging is always useful so that we can trace errors back to their sources without looking too hard.

A note from JavaScript In Plain English

We have launched three new publications! Show some love for our new publications by following them: AI in Plain English, UX in Plain English, Python in Plain English — thank you and keep learning!

We are also always interested in helping to promote quality content. If you have an article that you would like to submit to any of our publications, send us an email at submissions@plainenglish.io with your Medium username and we will get you added as a writer. Also let us know which publication/s you want to be added to.