Console Wrangling

What should you do around muting console.log, console.warn, and console.error when you push your code out to the real world?

The real answers are:

  • “Take out as many of them ahead of time.” At Udacity, we generally do now allow code with console.logs through the code review process unless it’s flagged on/off. Console.warn() and console.error() are still legitimate as they provide information when things go all pear-shaped.
  • “You should remove development console.log during your build step.” With the advent of grunt and gulp, you can whip up a build process and have it strip all your errant console.log()s out before your code heads to the server.

Buuuut sometimes we’re not using our own code; sometimes we’re dealing with legacy product; sometimes we’ve written something less-than-perfectly.

Then we can do this!

All of that goodness is just a quick and cosmetic fix to your console spewing all kinds of whatever you’ve left in there.

  • It keeps and uses the native console.log(), console.warn(), console.error() when you ask it to be chatty. No more “Your code tossed a console.log() from line 1 of log_wrapper.js”
  • It keeps your console silenced by default.
  • It allows you to turn it on from the console, and keeps a cookie around so page refreshes keep your console state.

Yup, it’s cosmetic. Yup, it’s more code. Yup, it’s useful for that quick fix while you work on cleaning up your code using the real answer. You are doing that, right?

 

Leave a Reply

Your email address will not be published. Required fields are marked *