У меня есть куча вызовов console.log() в моем JavaScript.
Должен ли я прокомментировать их до того, как я начну свое производство?
Я хотел бы просто оставить их там, поэтому мне не придется беспокоиться о повторном добавлении комментариев позже, если мне нужно будет больше отлаживать. Это плохая идея?
Это вызовет ошибки Javascript, завершив выполнение блока Javascript, содержащего ошибку.
Однако вы могли бы определить фиктивную функцию, которая не работает, когда Firebug не активен:
if(typeof console === "undefined") {
console = { log: function() { } };
}
Если вы используете любые методы, отличные от log, вам также нужно будет их заглушить.
Как уже указывали другие, оставив его, будут возникать ошибки в некоторых браузерах, но эти ошибки могут быть устранены путем ввода некоторых заглушек.
Однако я бы не только прокомментировал их, но и устранил эти строки. Просто кажется неаккуратным. Возможно, я педантичен, но я не думаю, что "производственный" код должен включать "отладочный" код вообще, даже в прокомментированной форме. Если вы вообще оставляете комментарии, эти комментарии должны описывать, что делает код, или аргументы позади него - не блоки кода с отключенным кодом. (Хотя, большинство комментариев должно быть автоматически удалено с помощью процесса миниатюризации. Вы минимизируете, правильно?)
Кроме того, за несколько лет работы с JavaScript я не могу вспомнить, когда-либо возвращался к функции и говорил: "Боже, мне жаль, что я не оставил эти console.logs здесь!" В общем, когда я "делаю" работу над функцией, а потом должен вернуться к ней, я возвращаюсь, чтобы исправить еще одну проблему. Независимо от этой новой проблемы, если бы console.logs из предыдущего раунда работы были полезны, я бы впервые заметил проблему. Другими словами, если я вернусь к чему-то, мне вряд ли понадобится точно такая же отладочная информация, какая мне нужна в предыдущих случаях.
Только мои два цента... Удачи!
Если у вас есть развертывание script, вы можете использовать его, чтобы отключить вызовы console.log(и минимизировать файл).
Пока вы на нем, вы можете бросить JS через JSLint и зарегистрировать нарушения для проверки (или предотвратить развертывание).
Это отличный пример того, почему вы хотите автоматизировать развертывание. Если ваш процесс позволяет вам публиковать файл js с console.logs в нем, в какой-то момент вы это сделаете.
Насколько я знаю, нет более короткого метода вырезания console.log, чем следующие 45 символов:
window.console||(console={log:function(){}});
Что первая из трех разных версий в зависимости от того, какие методы консоли вы хотите заглушить, все они крошечные, и все они были протестированы в IE6 + и современных браузерах.
Другие две версии охватывают различные методы консоли. Один из них охватывает четыре основы, а другой охватывает все известные методы консоли для firebug и webkit. Опять же, возможно минимальное количество файлов.
Этот проект находится в github: https://github.com/andyet/ConsoleDummy.js
Если вы можете думать о любом способе дальнейшего сглаживания кода, вклады приветствуются.
- EDIT - 16 мая 2012 г.
С тех пор я улучшил этот код. Он по-прежнему крошечный, но добавляет возможность включать и выключать вывод консоли: https://github.com/HenrikJoreteg/andlog
Это было показано в списке изменений
Вы должны хотя бы создать фиктивный console.log, если объект не существует, поэтому ваш код не будет вызывать ошибки на компьютерах пользователей без установленного firebug.
Другая возможность - инициировать ведение журнала только в режиме "отладки", то есть, если установлен определенный флаг:
if(_debug) console.log('foo');
_debug && console.log('foo');
Надеюсь, что это поможет кому-то - я написал обертку на некоторое время назад, немного более гибкое, чем принятое решение.
Очевидно, что если вы используете другие методы, такие как console.info и т.д., вы можете реплицировать эффект. когда вы делаете это со своей промежуточной средой, просто измените значение C.debug по умолчанию на false для производства, и вам не придется менять какие-либо другие строки кода/строки и т.д. Очень легко вернуться и отлаживать позже.
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");
это работает для меня...
if (!window.console) {
window.console = {
log: function () {},
group: function () {},
error: function () {},
warn: function () {},
groupEnd: function () {}
};
}
Понял, что у меня будет другая перспектива. Оставляя этот тип вывода видимым для внешнего мира в приложении PCI, вы несовместимы.
Я согласен, что консольный заглушка - хороший подход. Я пробовал различные консольные плагины, фрагменты кода, в том числе довольно сложные. У них у всех была проблема, по крайней мере, в одном браузере, поэтому я закончил с чего-то простого, как показано ниже, что является объединением других фрагментов, которые я видел, и некоторых предложений от команды YUI. Он функционирует в IE8 +, Firefox, Chrome и Safari (для 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;
};
Примечание.. Он поддерживает отключение ведения журнала на консоль с помощью флага. Возможно, вы могли бы автоматизировать это и с помощью скриптов сборки. Кроме того, вы можете открыть интерфейс или какой-либо другой механизм, чтобы перевернуть этот флаг во время выполнения. Конечно, вы можете получить гораздо более сложный уровень, с уровнями ведения журнала, ajax-представление журналов на основе порогового значения журнала (например, все операторы уровня ошибки передаются на сервер для хранения там и т.д.).
Многие из этих потоков/вопросов, связанных с протоколированием, похоже, считают операторы журналов в качестве кода отладки, а не кода инструментария. Отсюда и желание удалить записи журнала. Инструментарий чрезвычайно полезен, когда приложение находится в дикой природе, и уже не так легко подключить отладчик, или информация передается вам от пользователя или через поддержку. Вы никогда не должны регистрировать ничего чувствительного, независимо от того, где он был зарегистрирован, чтобы конфиденциальность/безопасность не подвергались риску. Когда вы думаете о регистрации в качестве инструментария, теперь он становится производственным кодом и должен быть записан в один и тот же стандарт.
В приложениях, использующих все более сложные javascript, я считаю, что инструментарий имеет решающее значение.
Как упоминают другие, в большинстве браузеров будет обнаружена ошибка. В Firefox 4 он не выдает ошибку, сообщение регистрируется в консоли веб-разработчика (новая в Firefox 4).
Одним из способов решения таких ошибок, которые мне очень нравились, была de && ошибка:
var de = true;
var bug = function() { console.log.apply(this, arguments); }
// within code
de&&bug(someObject);
Хороший однострочный:
(!console) ? console.log=function(){} : console.log('Logging is supported.');