Ваш подход к предупрежденям (warnings) в проекте?

Question

[Skie]

Не так давно у меня с коллегой случился небольшой холивар на тему подхода к предупреждениям (warnings) в проекте.


Один подход, считать предупреждения ошибками — "treat warnings as errors".

+ проект с предупреждениями не скомпилируется. Их необходимо будет исправить предварительно. А следовательно потенциальных проблем в коде будет меньше. В контексте Objective-C это особенно актуально.

— при использовании 3rd party библиотек высока вероятность что там будет определенное количество предупреждений, трогать которые лучше не стоит.


Другой подход — использовать предупреждения для своих нужд (например вместо TODO или как разного рода напоминания) макросом #warning xxxxx.

+ можно оставить активное напоминание что-то сделать или поменять в коде которое все будут видеть во время компиляции.

— злоупотребление таким подходом со временем приведет к подсознательному игнорированию предупреждений. Так же легко не заметить настоящее предупреждение от компилятора среди собственных, что иногда может привести к разного рода проблемам в работе приложения.


Хотелось бы услышать Ваше мнение/советы/подходы на эту тему.


Так же небольшая голосовалка в тему ;)

Answer 1

[TheHorse]

Как известно, ошибки тем дороже в исправлении, чем дольше они живут. Варнинги созданы специально для того, чтобы предупреждать о дефектах, которые могут привести к ошибкам. Их нужно править сразу, и это не сложно.

Определенные типы варнингов, можно просто отключить, если вы считаете, что они ошибочно вас предупреждают. Можно и нужно отключать для сторонних библиотек.

Использования варнингов для напоминания TODO, я считаю, следует делать тогда, когда это TODO должно быть реализовано в скором времени, имеет приоритет critical. На месяца запускать не следует.

В итоге. В проекте варнингов быть не должно, и их нужно сразу убирать:
* исправлять дефект
* Отключать классы варнингов, стороние варнинги.
* Реализовывать то, о чем они говорят, если это TODO.

P. S. По сути, все, что вы написали — логично, и не является взаимоисключающим. Тут не одно выбрать нужно, а все использовать, с умом.

Comments

[Skie]

Включение «treat warnings as errors» в свойствах проекта приводит к невозможности компиляции с предупреждениями, поэтому использовать #warning xxxxx становится невозможно. Именно поэтому они взаимоисключающие.

[TheHorse]

Можно действовать по принципу «treat warnings as errors», не включая это свойство в компиляторе.

[Skie]

Можно. Но это хорошо когда, человек один на проекте. Когда их несколько такое не всегда получится.

[TheHorse]

Lead-ы должны следить.

[Skie]

Зачем так конкретизировать? А если нет лидов?

[TheHorse]

А если программировать никто не умеет, а если компьютера нет? Не издевайтесь. Если не можете контролировать простые вещи, то и «treat warnings as errors» не поможет, его отключат. И вообще…

Answer 2

[Rowdy Ro]

В с++ проектах всегда включаю treat warnings as errors. Не вижу я смысла туду на этапе компиляции: если проект большой, при сборке эти варнинги могут убежать быстро и выхлопа от них 0. К тому же при обновлении gcc обломаться на варнинге бывает очень полезно, вплоть до обнаружения лика.

Туду реализую через коментарии кода -> doxygen -> profit.

Answer 3

[Pilot34]

Ставлю #warning для важных штук, которые надо поправить перед выпуском в аппстор. Например, если включена отладочная печать или стоит урл тестового сервера, который надо переключить на боевой.

Answer 4

[MikhailEdoshin]

Я стараюсь избавляться от предупреждений, хотя опцию в компиляторе не включаю. Разумеется не включаю и для сторонних библиотек — это дело их авторов. Писать TODO в коде, на мой взгляд, не самая лучшая идея — даже если это мой личный проект, лучше добавить отдельный файл со списком задач.

Answer 5

[ixSci]

Всегда включено treat warnings as errors. Сторонние библиотеки экранирую от генерации предупреждений. C++.

Answer 6

[egorinsk]

Но зачем использовать криво написанные библиотеки? Если их авторы игнорируют предупреждения компилятора, кто знает что там еще скрывается?

Comments

[Skie]

А кто сказал, что они криво написаны? Предупреждения выдает компилятор и это зависит от него. Сегодня все ок и предупреждений нет, а завтра выйдет новая версия и они появятся (реальная ситуация с новой версией XCode когда он стал ругаться на кривые параметры (несоответствие указанного типа реальному) в аргументах printf и иже с ним). Так же есть много хороших и больших библиотек типа OpenSSH где предупреждения есть и я не думаю что поэтому она станет плохой библиотекой.

[merlin-vrn]

Не знаю про openssh, а в openssl действительно есть места с warning. Намеренно оставленные, чтобы добавить случайности. т.е. это warning с точки зрения компилятора, а программисты знали, что делали, и намеренно использовали неинициализированные переменные.

[Skie]

Да точно, спутал. Это OpenSSL

Answer 7

[Eddy_Em]

Всегда -Wall, чтобы ничего не пропустить и -Werror, чтобы не было желания оставить ошибку не исправленной.