Old good trace

Я думаю, многие из тех кто работал с AS3 с теплом вспоминают команду trace, которая могла принимать кучу аргументов и выводить их значения в консоль.

Отлаживать приложения с помощью расстановки кучи логов, а потом мучительно просматривать вывод консоли стараясь понять как же это всё работает на самом деле — плохая привычка.
Старайся использовать брейкпоинты и отладчик!
Картиночка в тему ;)

Есть ситуации когда отладчик просто не работает на той платформе где вы ведёте основную разработку или запускать его сложно, или … тысячи других отговорок чтобы не использовать отладчик. И тогда вам на помощь приходит вывод в консоль.

Перейдя на Unity, я долго мучился с Debug.Log. Постоянно опечатывался и вместо “+” писал “,” — это вызывало ошибки компилятора, и я тратил тонну времени на поиск и исправление ошибки вывода, вместо того чтобы разбираться собственно с проблемой для который он был использован. Даже по прошествию полутора лет я иногда путаюсь с этими двумя символами.

Признайся, Debug.Log адово неудобный. Из всех способов подсветить лог у него есть warning и error. И error уж больно жирно, а warning в 99% случаев вырублен за ненадобностью и из-за того что другие скрипты слишком громко вопят о всяких вещах, на которые уже нет сил обращать внимание. Вот, ты знал что вывод в консоли можно раскрашивать в разные цвета? Что можно писать жирным шрифтом, а размер шрифта можно регулировать? Я не знал до поры до времени.

Однажды, общаясь с Антоном Карловым, мы с ним совместно решили— хватит это терпеть! Нам нужен trace из AS3! Попытались написать каждый свой. Честно говоря у меня не получилось. Сдулся в момент когда нужно было принять кучу непонятных объектов, а потом превратить их в строки. Я пошёл по сложному пути и забрёл в тупик. Компилятор всё время ругался на типы объектов, свободного времени становилось всё меньше и меньше, в итоге я забил и забыл. Как-то в очередной сеанс связи, Антон скинул простенький скрипт который работал как нужно! Правда, там была куча специфичного кода для собственного удобства. Мне же нужен был голый логгер без финтифлюшек. Я вырезал всё что мне не нравилось, переименовал класс из AntLog в D (AntLog.Trace vs D.Log)для краткости и пользовался им долгое время.

Потом прочитал про то что Debug.Log медленная скотина, о том что надо избавляться от конкатенации строк в игре, и прочее-прочее. Я и раньше об этом знал, но не придавал этому особого значения.

И вот, на прошлой неделе, я исправил нагрев андроидов тем что закомментировал все логи в одной нашей игре. Вообще я стараюсь не оставлять логов. На прошлой работе, было строгое правило, которому я следую до сих пор:

Перед релизом все логи либо комментировать, либо оборачивать в #ifdef, либо удалять.

Разработчики же той игры грешили логами в продакте.

В последний раз я переписал D.Log так чтобы использовался только StringBuilder, убрал пару подозрительных мест, переделал некоторые методы чуть оптимальнее и решил что этим стоит поделиться с общественностью :). Да здравствует OpenSource!

Сам скрипт занимает меньше места, чем я тут текста понаписал. Может он будет тебе помогать отлаживать скрипты чуть проще и удобнее. Пользуйся — если не страшно :).

Основная фича, это отсутствие конкатенации строк при передачи аргументов для вывода отладочной информации. То есть используется “,” а аргументы передаются через params. Это чуть ускоряет работу логгера, ибо в конце-концов используется StringBuilder (но это всё, конечно, спички).

Часто возникает ситуация когда нужно в лог передать 2–3 параметра для проверки, может просто текстовую строку склеить с аргументом, для того чтобы отличать место вызова по сообщению:

Debug.Log("Some value:" + someInteger); // Some value:123
D.Log("Some value:", someInteger); // Some value: 123

Вроде ерунда, но передавать значения в качестве аргументов на мой взгляд гораздо правильнее чем мучаться с конкатенацией и привидением типов. Из-за этого очень часто возникают такие ошибки как:

Debug.Log(1 + "+" + 1 + "=" + 1 + 1); // 1+1=11
D.Log(1, "+", 1, "=", 1 + 1); // 1 + 1 = 2

Все значения перед выводом проверяются на Null, и оно выводится в виде различаемого слова а не пустой строкой:

Object A = null;
Debug.Log(A); //
Debug.Log((A == null ? "Null" : A)); // Null
D.Log(A); // Null

Если после этого ты не побежал скачивать этот замечательный класс, то как тебе такое?:

D.Pretty("Red").Red.Log();
D.Pretty("Green").Green.Log();
D.Pretty("Blue").Blue.Log();
D.Pretty("Bold and Pink").Color("#FF0066").Bold.Log();
D.Pretty("Bold and Yellow and Large").Yellow.Size("24").Bold.Log();

Ещё, если не объявлен дефайн DEBUG, то логи не будут выводиться в продакте, вообще их лучше удалять вручную, но и так уже что-то.

Есть конечно и минусы:

  1. Путь в логах увеличивается на две строки (вызов метода Log), так что придётся вглядываться чуть внимательнее, правда, учитывая что эти выводы не должны долго жить, и если их нормально пометить — то найти их будет просто.
  2. Вывод в консоль, например adb, будет загрязнён тегами <B><Color> и т.д. если будете их использовать.
  3. Лишний скрипт, который придётся таскать с собой в каждый проект, лишняя статическая зависимость ;(.

Используй на свой страх и риск. Вот ссылка, если не нашел её в тексте: D.cs

P.S. Ещё раз, большое спасибо Антону Карлову за то что сэкономил мне просто кучу времени в моей повседневной работе, а также всем читателям что подписались на мой блог ;)

P.P.S. Сейчас в черновиках уже 3 статьи в процессе написания, одна из них практически закончена, нужно только потратить пару-тройку часов на снятие скриншотов и проверку, жди, скоро всё будет :). Эта статья коротыш, которую я решил написать только чтобы поделиться полезным инструментом.

P.P.P.S. Микрофон для стрима я купил, но так-как он конденсаторный от звуковой карты питания не хватает и он звучит очень тихо и с помехами, жду фантомное питание на 48 вольт, если тебе это что-то говорит.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.