Прекратите использовать console.log для всего. Я вижу, как многие разработчики регулярно используют console.log метод таким образом, который я считаю неправильным.
Недостатки использование console.log для отладки
Многие разработчики до сих пор используют console.log метод для отладки своего приложения. Например, чтобы убедиться, что код запускается или что переменная имеет правильное значение.
В этом есть несколько недостатков.
Вы не можете отследить жизненный цикл вашего приложения, лишь отслеживаете значение переменной в данный момент времени.
Часто случается так, что console.log забываются в нескольких местах кода, что кроме гипотетической потери производительности (мизерной, но размер которой варьируется в зависимости от объема данных, вызываемых через метод console.log) загрязняя ваш код.
Решение состоит в том, чтобы использовать инструменты отладки, предоставляемые вашим браузером. Это может потребовать некоторого обучения, но вознаграждение перевешивает усилия.
Таким образом, вы будете иметь полный контроль над жизненным циклом вашего кода и не забудете свой console.log в своем коде.
Смотреть. Отладка JavaScript с помощью Chrome DevTools или Использование отладчика JavaScript от Mozilla Firefox.
Использование только метода console.log
Многие разработчики используют console.log для вывода любых видов сообщений: информации, ошибок, предупреждений и т. д.
Объект console, предоставляет доступ к отладочной консоли браузера и имеет множество методов с очень специфическими применениями.
Вот исчерпывающий список наиболее часто используемых методов:
console.error → Выводит сообщение об ошибке
console.warn → Выводит предупреждающее сообщение
console.info → Выводит информативное сообщение (особый рендеринг в Firefox, но технически идентичен console.log)
console.log → Выводит глобальное сообщение
console.debug → Выводит сообщение, если консоль настроена на показ сообщений уровня отладки
console.table → Выводит данные массива/объекта в виде таблицы
console.time (в связке с console.timeEnd) → Позволяет установить таймер, чтобы увидеть, как долго задача должна быть выполнена
Конкретный пример использования console.debug метода
Лично я использую debug метод в трех ситуациях.
В первом случае мы хотим быстро отобразить часть информации на экране (например, значение переменной). Данное сообщение по умолчанию будет «скрытым» для пользователя (за исключением случаев, когда консоль настроена в специальном режиме).
Во втором случае мы хотим использовать метод в качестве привязки к нашему исходному файлу (мы также можем использовать возможности отладчика, но лично я предпочитаю этого не делать).
В третьем случае мы хотим использовать отладку в работающем приложении. Например, функция, зарегистрированная непосредственно в объекте window, может инициировать вывод в пользовательскую консоль. Этот вариант может быть полезен, когда в нашем распоряжении нет среды для тестирования и когда ошибку, обнаруженную клиентом, трудно воспроизвести в среде разработки.
Удалить console.debug из рабочей версии
За исключением третьего случая, который мы только что рассмотрели, я советую вам использовать что-то вроде git pre-commit хука или плагина для проверки методов или ключевых слов, которые вы не хотите видеть в рабочей версии приложения.
Вы можете использовать UglifyJS для фильтрации по этим ключевым словам.
Спасибо, за внимание ????.
Текст переведен с английского: оригинал
Комментарии (23)
TimsTims
13.07.2022 17:28+15console.log забываются в нескольких местах кода, что кроме гипотетической потери производительности
По сравнению с тем, что js-пакеты после сборки превращаются в 10MB+ монстра, вызовы console.log кажутся песчинкой в пустыне по затраченным ресурсам. Я уже молчу про остальной собираемый фронт, который грузит проц на 100% в течение 10 секунд.
А уж сколько ресурсов кушает браузер при обычном скролле... вывод console.log - это точно цветочки.
Данное сообщение по умолчанию будет «скрытым» для пользователя
Не каждый пользователь вообще открывает консоль через F12. А если уж открыл и читает какие-то значения, которые сыпятия консоль, то уж точно ему будет не сложно включить режим дебага.
Решение состоит в том, чтобы использовать инструменты отладки, предоставляемые вашим браузером
Статья как-будто из 2010х, но Chrome Dev Tools появился как-бы позднее. Сейчас многие фронты много раз собираются разными сборщиками, которые многократно пакуют и изменяют код. Удачи поставить точку останова там, где 10MB javascript'а написан в одну строчку.
По итогу, скажем так, console.log - уж точно не главная боль современного frontend'а.
space2pacman
13.07.2022 17:31+9По сравнению с тем, что js-пакеты после сборки превращаются в 10MB+ монстра, вызовы console.log кажутся песчинкой в пустыне по затраченным ресурсам.
Мне пришлось сделать дома кластер из XEON'ов чтобы перенести вывод консоли на него.
radtie
13.07.2022 17:55+1Так в non-prod-режиме код собирается обычно с source-maps и дебаггер останавливается в нужной строке исходника.
А вообще для такого есть абстракции логгеров, вставляешь в код (даже оставляя в продакшене), чем больше тем даже лучше, всякие trace / debug, а потом с помощью LogLevel определяешь что выводить.
А подменяя абстракции, можно вместо вывода в консоль, хоть отсылать логи на сервер, хоть складывать в localStorage, меняя только флаги сборки.
Т. ч. я считаю, что неиспользование console.log, хоть и не "главная боль", но у ж точно показатель культуры разработки.
kahi4
13.07.2022 18:52+1Так в non-prod-режиме код собирается обычно с source-maps и дебаггер останавливается в нужной строке исходника.
Но есть три проблемы, из-за которых я этим редко пользуюсь:
Оооочень медленно. Пока браузер прогрузится в дебаг режиме, я пять раз перезапустить успею. И ресурсы выедает как не в себя (наверное из-за этих же соурсмапов)
Останавливается почти там где нужно (не всегда потому что после бейбеля код может очень сильно отличаться), но вместо осмысленных переменных вокруг показывает обфусцированный мусор.
Зачастую мне нужно проверить тот же реакт компонент, который перерендеривается по 15 раз и интересуют только последняя пара раз. Это слегка мучительно
бонус: режим «остановка на исключениях» был бы супер полезный если бы недобросовестные разработчики не принялись кидаться и ловить ошибки налево-направо для всех этих suspense и чего бы то ни было.
Но иногда дебаггер - единственное что спасает.
Sadler
13.07.2022 19:52+1Удачи поставить точку останова там, где 10MB javascript'а написан в одну строчку.
Использую source maps, особых трудностей в отладке не испытываю. С другой стороны, не понимаю агр автора в сторону console.log: тоже вполне полезный инструмент, иногда приходится и им трейсить.
Metotron0
13.07.2022 17:44+4Список исчерпывающий, но console.assert и console.count в нём почему-то нет.
KoCMoHaBT61
13.07.2022 17:55+4Много чего нет. console.trace, например. А всё это можно посмотреть с помощью отсутствующего console.dir(console)
NebulusPrima
13.07.2022 18:14Для отладки - почему бы и нет? Так, например, можно посмотреть, правильно ли работает цикл, не заморачиваясь. Главное не забыть убрать
GothicJS
13.07.2022 18:18+9Да всегда будут использовать console.log, потому что это удобно. Прекратите запрещать людям делать то, что им удобно)
P.S. Понятно, что это не к переводчику посыл)
Vest
13.07.2022 19:32А потом переключаешь лог в уровень DEBUG, что аж браузер подвисает от большого количества всевозможных сообщений.
yarkov
13.07.2022 21:23+1Часто случается так, что console.log забываются в нескольких местах кода
Для этого линтер существует
Alexandroppolus
13.07.2022 22:40от линтера здесь толку мало - просто забывают console.log вместе с eslint-disable-next-line перед ним
Marcelinka
14.07.2022 01:43Я таким образом делала, в проекте линтер настраивала с возможностью писать console.log, а потом запуская линтер в CI дописывала правило через команду в терминале. Таким образом при локальной разработке ругани не было, а вот на стадии принятия MR он отваливался
crucian13
14.07.2022 10:50Я пользуюсь линтером, который проект собирает и выводит в консоль что надо, но в среде разработки показывает ошибку, которую нельзя не увидеть перед пушем, например
nickerlan
13.07.2022 22:32+1Лайфхак: если пользуюсь временными выводами данных в консоль, с какого-то момента первым аргументом всегда пишу имя функции или переменной о которой идет речь. Это позволяет понимать о чем речь, а главное - быстро находить тех кто уже почем зря мусорит в консоль, если по тем или иным причинам еще не хочется выкидывать все отладочные данные.
16bc
13.07.2022 22:32А про газлайтинг разработчика, вооружённого console.log со стороны банды промисов в состоянии гонки где?
Hrodvitnir
14.07.2022 04:48+7многие разработчики регулярно используют console.log метод таким образом, который я считаю неправильным
Простите, больше не буду
dizel3d
14.07.2022 23:57+2Вообще-то у console.log есть и преимущества перед debugger:
Остаётся история вызовов. Я вижу, как менялось состояние. С дебаггером приходится вспоминать, что было, в каком порядке и сколько раз.
Не останавливает выполнение кода на каждом вызове, а просто пишет на экран. Для ряда кейсов так банально быстрее получается.
Как следствие из п.2 не портит тайминги. Например, с дебаггером может случиться нежелательный тайм-аут, reject промиса, потому что код остановился, а часики-то тикают :-)
А ещё есть ситуации, когда дебаггер невозможно включить. Например, в вебвью сторонних приложений или на удалённом iOS устройстве. Тогда и, прошу прощения, alert может пригодиться. :-D
Expany
Даже сам Хабр не готов к таким вещам.
Gobl1n
Что характерно - статьи с тем же самым содержанием)