Плохая идея оставить “console.log ()” звонит в Ваш производственный код JavaScript?

Как уже указывали другие, оставление этого параметра вызовет ошибки в некоторых браузерах, но эти ошибки можно обойти, вставив некоторые заглушки.

Однако я бы не только прокомментировал их, но сразу удалите эти строки. Просто поступать иначе - это небрежно. Возможно, я педантичен, но я не думаю, что "производственный" код вообще должен включать "отладочный" код, даже в закомментированной форме. Если вы вообще оставляете комментарии, эти комментарии должны описывать, что делает код, или причины этого, а не блоки отключенного кода. (Хотя большинство комментариев должно удаляться автоматически в процессе минификации. Вы минимизируете, не так ли?)

Кроме того, за несколько лет работы с JavaScript я не могу припомнить, чтобы когда-либо возвращался к функции и говорил: «Ну и дела, Хотел бы я' Я заметил проблему с первого раза. Другими словами, если я к чему-то вернусь, мне вряд ли понадобится та же самая отладочная информация, что мне требовалась в предыдущих случаях.

Только мои два цента ... Удачи!

Только мои два цента ... Удачи!

Если у вас есть сценарий развертывания, вы можете использовать его, чтобы исключить вызовы console.log (и минимизировать файл).

Пока вы работаете, вы можете бросить ваш JS через JSLint и записать нарушения для проверки (или предотвращения развертывания).

Это отличный пример того, почему вы хотите автоматизировать развертывание. Если ваш процесс позволяет вам опубликовать файл js с console.logs в нем, в какой-то момент вы сделаете это .

Вы должны хотя бы создать фиктивный console.log , если объект не существует, чтобы ваш код не вызывал ошибок на машинах пользователей без установленного firebug.

Другой возможностью было бы запускать ведение журнала только в «режиме отладки», то есть если установлен определенный флаг:

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.

, похоже, у меня это работает ...

if (!window.console) {
    window.console = {
        log: function () {},
        group: function () {},
        error: function () {},
        warn: function () {},
        groupEnd: function () {}
    };
}

Хороший однострочник:

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