Здравствуйте, johny5, Вы писали:

A>>>>держать treat warnings as errors включенным
CC>>>Это как по мне обязательно и безальтернативно.

A>>Соглы. Для этого и нужен #pragma disable, который позволяет игнорировать ворнинги точечно, а не все сразу. Навскидку пара примеров: хедер может придти из источника, над которым нет власти, а это библиотека, которую нельзя не использовать. Ну и deprecated, когда в нём почему-либо есть нужда.

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

Про обоснование это хороший поинт. Я как раз порылся в старых проектах, вспомнить не мог, зачем там всё так, и что за 4995 и 4996 встречаются чаще всего. Надо было в комментариях обосновывать. Смутно вспоминаю, что с переходом на более новые функции ломалась сборка под XP. В общем, маркетологам дали рычаг давления на программистов в виде __declspec(deprecated)/[deprecated]] (если, конечно, правильно вспомнил), надо же как-то с этим было бороться.

А с остальным согласен. Вот с этим особенно:

>Есть правда и альтернативы PR-ам: парное программирование (тут тоже упоминали) звучит многим нереалистично, на практике можно брать оттуда какие то элементы. И вот в одной из контор, в целях ревью мы как раз садились с программистом вместе и он показывал код и рассказывал что и как код делает, какую он задачу решает, какие абстракции он ввёл и зачем и т.д.. Золотые были времена.

Аналогичный опыт, мы с коллегой работали парой над одним продуктом, каждый у себя больше времени проводил, но постоянно друг к другу ходили, обсуждали всё, критиковали, делились хорошими практиками и т.п. "Золотые были времена"!

Я так обобщу эту мысль. Хорошо, когда в команде обсуждения, критика, обмен идеями, и в целом — коммуникация на высоте. А когда это всё заменяют паллиативом в виде бездушного CR, результат соответствующий.