Bad idea to leave “console.log()” calls in your production JavaScript code?

Question

I have a bunch of console.log() calls in my JavaScript.

Should I comment them out before I deploy to production?

I\'d like to just leave them th

Answer 1

If you have a deployment script, you can use it to strip out the calls to console.log (and minify the file).

While you're at it, you can throw your JS through JSLint and log the violations for inspection (or prevent the deployment).

This is a great example of why you want to automate your deployment. If your process allows you to publish a js file with console.logs in it, at some point you will do it.

Answer 2

I agree that the console stub is a good approach. I've tried various console plugins, code snippets, including some fairly complex ones. They all had some problem in at least one browser, so I ended up going with something simple like below, which is an amalgamation of other snippets I've seen and some suggestions from the YUI team. It appears to function in IE8+, Firefox, Chrome and Safari (for Windows).

// To disable logging when posting a production release, just change this to false.
var debugMode = false;

// Support logging to console in all browsers even if the console is disabled. 
var log = function (msg) {
    debugMode && window.console && console.log ? console.log(msg) : null;
};

Note: It supports disabling logging to the console via a flag. Perhaps you could automate this via build scripts too. Alternatively, you could expose UI or some other mechanism to flip this flag at run time. You can get much more sophisticated of course, with logging levels, ajax submission of logs based on log threshold (e.g. all Error level statements are transmitted to the server for storage there etc.).

Many of these threads/questions around logging seem to think of log statements as debug code and not code instrumentation. Hence the desire to remove the log statements. Instrumentation is extremely useful when an application is in the wild and it's no longer as easy to attach a debugger or information is fed to you from a user or via support. You should never log anything sensitive, regardless of where it's been logged to so privacy/security should not be compromised. Once you think of the logging as instrumentation it now becomes production code and should be written to the same standard.

With applications using ever more complex javascript I think instrumentation is critical.

Answer 3

As other have mentions it will thrown an error in most browsers. In Firefox 4 it won't throw an error, the message is logged in the web developer console (new in Firefox 4).

One workaround to such mistakes that I really liked was de&&bug:

var de = true;
var bug = function() { console.log.apply(this, arguments); }

// within code
de&&bug(someObject);

Answer 4

A nice one-liner:

(!console) ? console.log=function(){} : console.log('Logging is supported.');

Answer 5

Figured I would share a different perspective. Leaving this type of output visible to the outside world in a PCI application makes you non-compliant.