Интересная фишка.
А я сделал по другому — простую функцию и там прописал Log.d..., и поставил условие если BuildConfig.DEBUG то выводить логи, а иначе нет, и все проблемы с логами в релизе испарились)
Хотел спросить: а как быть, если над проектом работает >1 человека и код хранится в удаленном репозитории? Логи позволяют довольно удобно отслеживать правильность выполнения тех или иных операций, а покрывать бряками проект на >100 файлов вручную как то сложно. Да и порой приходится делать поиск по всему проекту оперируя строками из логов, чтобы понять что именно пошло не так.
Насчет тестов я с вами полностью согласен. Но во первых есть легаси код, а во вторых далеко не весь код покрывается тестами. Мне кажется довольно удобным, когда я сразу могу увидеть, что сервер прислал что то не то, в момент когда я отлаживаю совершенно другие вещи, или например давно написанная обертка для энкодера видео в h264 с чем то не справилась и написала об этом в лог.
Логи действительно выводятся только в дебажных сборках, у нас самописный логгер с некоторым количеством плюшек, одной из которых является невывод логов в релизных сборках. Да и без этого можно обойтись, proguard вполне себе выпиливает логи.
Код действительно становится чище, факт. Но никто не заставляет писать логи в каждой второй строке, а потом на них всех смотреть. Именно для этого есть разные уровни логов, фильтры logcat в IDE и возможность покрасить логи определенного уровня определенным цветом. Но тут уже у кого как принято и кому как нравится.
Логирование в Android Studio без кода