Joshua Worden

@nathansmith Wow, you put a lot more effort into that than I did!

Makes sense though, if console.log is native to the browser it shouldn't be able to be overridden. Would probably open a few security holes if third-party code could override core browser methods.

Currently we minify our JS before caching it, so I think for us the best solution would be to strip logging during that process. Unfortunately we still need to provide a fake console.log method for IE browsers because we can't control whether or not third-party ads will contain logging calls (and they fairly frequently do, unfortunately).

All that said, I like your approach. If only I could get the rest of our team on board :)

@nathansmith

Good point. I guess we're not doing debugging correctly ;)

Ours only covers the IE issue, rather than addressing logging based on the environment, I guess I didn't read your post carefully enough.

Wouldn't your solution require developers to use log() rather than console.log() though? Could the same solution be achieved by extending console.log rather than creating a new function (forgetting for a moment that leaving logging statements in is doing it wrong), and assuming developers will use it?

Neat solution. We assume that logging shouldn't be on in production, so at the top of our included javascript we have the following to prevent IE errors:

var console = console || { log: function() {} };