Запустил “make build” и получил 156 ворнингов:(… Хотя, достаточно быстро получил более радужное число - 69, что тоже не мало. Нужно фиксить дальше, а пока - немного очень IMHO на эту тему.
Отключать или нет параметр “mark warnings as errors” (название может отличаться, но суть остается той же) - часто решают для конкретного проекта и/или команды. Иногда это не мешает работы продукта. Я бы сказал что в 98% случаев это не мешает, зато остаются 2%. И баги, попавшие в те самые 2%, часто являются самыми трудновоспроизводимимы и затратными по времени на исправления.
Итак, из-за чего появляются warnings? Самые частиы причины - это:
Что плохого в использовании deprecated API? Ничего, если приложение будет удалено не посже, чем сразу после перговго запуска. В противном случае, рано или поздно, после очередного обновления используемой платформы и/или фреймворка что-то перестанет работать, т.к. deprecated код будет удален. Таким образом, ваш код, который использует устаревший API фреймворка, автоматически становится deprecated :). Готовы ли вы писать заведомо legacy код?
С недокументированными возможностями дела обстоят похожим образом, за исключением того, что никто не гарантирует что этот API будет работать так же, как и сейчас.
Код, который не соответствует стандартным гайдлайнам, как минимум, - странный. IMHO. Нет, я понимаю, что при использовании StyleCop (для C#) практически невозможно писать код, соответствующий всем его требованиям, но для того же Python’а, держать код в соответствии с PEP-8 достаточно просто. Трудности бывают только с 80-ю символами в строке. С PyLint все немного сложнее. Но никто не заставляет выполнять все требования. Главное - здравый смысл и правильная настройка инструментов, которые используются.
Проблемы с настройкой окружения. Тут не буду много писать, т.к. эта тема тянет на отдельный пост в блоге, который уже давно хочется написать. Скажу только то, что один и тот же код (id коммита, tag, и т.д.) должен, по возможности, собираться одинаково на всех используемых окружениях. Это, как правило, рабочий ПК разработчиков и тестировщиков и билд-серверы. Иначе где-то что-то пойдет не так.
Не попал в мой классификацию еще один случай - содержимое stderr. Бывает, что только туда пишуться какие-либо предупреждения, которые остаются непрочитанными. Давно уже руки тянуться помечать все билды как failed, если что-то есть в stderr, но пока это сделать не получается, т.к. “хороший продукт !== работающий и/или безбажный продукт”, а “хороший продукт == радующий пользователя/заказчика продукт”. Как-то так.