It will cause Javascript errors, terminating the execution of the block of Javascript containing the error.

You could, however, define a dummy function that's a no-op when Firebug is not active:

if(typeof console === "undefined") {
    console = { log: function() { } };
}

If you use any methods other than log, you would need to stub out those as well.

As others have already pointed it, leaving it in will cause errors in some browsers, but those errors can be worked around by putting in some stubs.

However, I would not only comment them out, but outright remove those lines. It just seems sloppy to do otherwise. Perhaps I'm being pedantic, but I don't think that "production" code should include "debug" code at all, even in commented form. If you leave comments in at all, those comments should describe what the code is doing, or the reasoning behind it--not blocks of disabled code. (Although, most comments should be removed automatically by your minification process. You are minimizing, right?)

Also, in several years of working with JavaScript, I can't recall ever coming back to a function and saying "Gee, I wish I'd left those console.logs in place here!" In general, when I am "done" with working on a function, and later have to come back to it, I'm coming back to fix some other problem. Whatever that new problem is, if the console.logs from a previous round of work could have been helpful, then I'd have spotted the problem the first time. In other words, if I come back to something, I'm not likely to need exactly the same debug information as I needed on previous occasions.

Just my two cents... Good luck!

Update after 13 years

I've changed my mind, and now agree with the comments that have accumulated on this answer over the years.

Some log messages provide long-term value to an application, even a client-side JavaScript application, and should be left in.

Other log messages are low-value noise and should be removed, or else they will drown out the high-value messages.

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.

To my knowledge there is no shorter method of stubbing out console.log than the following 45 characters:

window.console||(console={log:function(){}});

That's the first of 3 different versions depending on which console methods you want to stub out all of them are tiny and all have been tested in IE6+ and modern browsers.

The other two versions cover varying other console methods. One covers the four basics and the other covers all known console methods for firebug and webkit. Again, in the tiniest file sizes possible.

That project is on github: https://github.com/andyet/ConsoleDummy.js

If you can think of any way to minimize the code further, contributions are welcomed.

-- EDIT -- May 16, 2012

I've since improved on this code. It's still tiny but adds the ability to turn the console output on and off: https://github.com/HenrikJoreteg/andlog

It was featured on The Changelog Show

You should at least create a dummy console.log if the object doesn't exist so your code won't throw errors on users' machines without firebug installed.

Another possibility would be to trigger logging only in 'debug mode', ie if a certain flag is set:

if(_debug) console.log('foo');
_debug && console.log('foo');

Hope it helps someone--I wrote a wrapper for it a while back, its slightly more flexible than the accepted solution.

Obviously, if you use other methods such as console.info etc, you can replicate the effect. when done with your staging environment, simply change the default C.debug to false for production and you won't have to change any other code / take lines out etc. Very easy to come back to and debug later on.

var C = {
    // console wrapper
    debug: true, // global debug on|off
    quietDismiss: false, // may want to just drop, or alert instead
    log: function() {
        if (!C.debug) return false;

        if (typeof console == 'object' && typeof console.log != "undefined") {
            console.log.apply(this, arguments); 
        }
        else {
            if (!C.quietDismiss) {
                var result = "";
                for (var i = 0, l = arguments.length; i < l; i++)
                    result += arguments[i] + " ("+typeof arguments[i]+") ";

                alert(result);
            }
        }
    }
}; // end console wrapper.

// example data and object
var foo = "foo", bar = document.getElementById("divImage");
C.log(foo, bar);

// to surpress alerts on IE w/o a console:
C.quietDismiss = true;
C.log("this won't show if no console");

// to disable console completely everywhere:
C.debug = false;
C.log("this won't show ever");

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.

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);