- 1
- 2
- 3
- 4
- 5
if(false || DEBUG)
{
System.out.print("analysis: "+Integer.toBinaryString(analysis));
System.out.println(", "+WalkerFactory.getAnalysisString(analysis));
}-
Java / Говнокод #8721
+75
Вычурный способ делать комментарии. Пример может и боян, но зато где: в исходниках API Android 2.2 Froyo.
Запостил:
google-moogle,
04 Декабря 2011
Follow us!
или я не вкурил, или автор не увидел замечательное быть или не быть "false||DEBUG"?
Перекомпилять приложение чтобы изменить уровень логгирования - это маразм. Проект, над которым я работаю, собирается 15 минут, а потом ещё 10 минут деплоится.
А вообще, да. Как уже правильно сказали выше, если не осилил логгинг, то ССЗБ.
Допустим мне надо посмотреть, что твориться во второй секции, при этом меня совсем не интересует, что происходит в 1-й и 3-й. Решение:
А полноценное логирование нужно далеко не всегда и далеко не везде.
ПЫСЫ Кстати, как в данном случае логирование поможет?
В java его гораздо проще получить их коробки, чем городить вот такие унылые велосипеды
может ответите на вопрос?
я не противник логгирования. просто есть ситуации, когда оно нафиг не нужно.
> есть ситуации, когда оно нафиг не нужно
И это не самый удачный пример такой ситуации.
Аккуратным выбором уровней логгирования для совершаемых операций. В JUL их более чем дохрена:
SEVERE (highest value)
WARNING
INFO
CONFIG
FINE
FINER
FINEST (lowest value)
Повторюсь, что я ни в коей мере не утверждаю, что логгирование не нужно. Просто бывают ситуации, когда логгированием не обойтись.
П. С. Я никому ничего не доказываю =) Странно, что вы это до сих пор не поняли. Просто надо иногда смотреть на код с другой стороны, надо пытаться понять почему он написан именно так, а не с точки зрения каких-то общих правил и догм. На этом ресурсе бытует мнение, что если что-то сделано не по правилам - то это говно.
> if(false || DEBUG) {//section1}
LOGGER.fine("holy crap");
> if(true || DEBUG) {//section2}
LOGGER.info("holy integrals");
> if(false || DEBUG) {//section3}
LOGGER.fine("holy aliens");
Есть ещё, к примеру, фильтры.
А вообще мне приходилось анализировать логи размером в несколько гигабайт: это сложно только на первый взгляд ;).
Просто в данной ситуации, я уверен, ни о каких гигабайтах речи и не идет. И вообще логирования тут быть, скорее всего, не должно. Это просто место, которое отладил и забыл.
В моем конкретном примере задача состояла в отладке кастомного виджета. Интересовали события focusGained, focusLost, mouseEnter, а также их комбинации. Меняя три булевых флага я сделал это намного быстрее, чем если бы игрался с настройками логирования.
Просто у меня обычно цикл build - install занимает много времени, дебажиться возможности нет, а проблемы бывают сложные. Да и логгирование уже давно настроено как нужно.
Если вам было и удобно и вы работали продуктивно - ваше право. На вкус и цвет все фломастеры разные.
компилятору придется делать одинаковый универсальный бинарник
т.е. уже по размеру удар
ну и я, конечно, не знаток синтаксиса jul, но ведь компилятор не может не делать вычисление в рантайме передаваемых аргументов в функцию записи в лог, даже если по уровню лога она не должна никуда дальше попасть?
поэтому в наших С++ проектах мне не западло в 99% случаев делать
verbose() << "some text which often ignored, " << somevar << etc << std::endl;
и только в 1% уже заморачиваться
if (logger.enabled(log::level::verbose)) {
// do some heavy intermediate process and output result to log
}
а в embedded проектах на С, где ресурсы ограничены, таки приходится экономить и бинарник и скорость и делать всегда
#if _DEBUG_CATEGORY_SUBCATEGORY
// do some debug and log
#endif
и перекомпиливать, чтобы тестить debug в песочнице, а в поле release работал быстро быстро и правильно
думаю, в андроиде эти требования вполне актуальны
в моих С++ логах всё упомянутое можно юзать как бекенд, хотя на практике самыми востребованными бекендами оказались свой filerotate и слив по udp на отдельную машину
Зачем? Гарантированной доставки там нет?