Хорошие подходы для обеспечения построения с повышенным уровнем предупреждения для нового кода C ++

Question

Я унаследовал большую кодовую базу C ++ для нескольких приложений Windows, которая успешно используется многими клиентами.

• База кодов большая,> 1 мельница LOC.
• База кодовимеет историю более 15 лет.
• В некоторых областях кодовая база доминирует в стиле программирования C и / или не очень современном стиле C ++, например, не использует стандартные коллекции и алгоритмы C ++.
• К сожалению, кодовая база была скомпилирована только с уровнем предупреждения 2 (/ W2 в Visual C ++).Я хотел бы перейти на уровень 3 (/ W3), чтобы повысить безопасность и подготовиться к 64-разрядной.

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

Что было бы хорошим подходом для обеспечения и обеспечения того, чтобы новый код, зафиксированный в кодовой базе, компилировалсяс повышенным уровнем предупреждения?

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

Answer 1

Я бы даже пошел до уровня предупреждения 4 (/W4).

---

Поскольку вы используете Visual Studio, довольно просто подавить надоедливые предупреждения, такие как сравнение со знаком и без знака:

#pragma warning(disable:NNNN)

Где NNNN - номер вашего предупреждения.Теперь поместите все эти отключенные предупреждения в файл заголовка (скажем, «tedious_warnings.h») и принудительно включите этот файл заголовка везде - «Свойства проекта» -> C / C ++ -> «Дополнительно» -> «Принудительное включение файла».
Позже,или, что лучше, как можно скорее, уберите форсированное включение и пройдите через предупреждения, поскольку большинство из них довольно легко исправить (вместо size_t, если int и т. д.).

Answer 2

Возможно, вы могли бы создать новый код в отдельных библиотеках или библиотеках.Таким образом, вы можете применить свой более высокий уровень предупреждений (и я бы сказал, перейдите к / W4 и будьте готовы отключить несколько предупреждений MS dfter, а не соглашаться на / W3) без необходимости просматривать тысячи предупреждений из старого кода.

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

Answer 3

вам может не понравиться ответ ...

удалите предупреждения, исправив ошибки.

Я очень требователен к уровням предупреждений;даже я игнорирую предупреждения, которые мне не нужны для исправления, особенно когда уровень предупреждения высокий и время сборки велико.тем временем новые (проскальзывают) в больших кодовых базах.постепенное их удаление не очень хорошо, по моему опыту - они имеют тенденцию игнорироваться, если шум слишком высокий или не применяется.

вам нужно уменьшить предупреждающий шум, чтобы люди могли видетьпредупреждения, которые они добавляют (на желаемом уровне предупреждения).

для достижения необходимого / необходимого уровня соответствия, сделайте его приоритетом.

, если вы не знаете, выполняются ли преобразования /сравнения действительны, вы всегда можете использовать шаблонную функцию с действием ошибки (assert, throw, log) для выполнения логики в случае сомнений.

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

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

Answer 4

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

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

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

Answer 5

Я бы использовал инкрементальный подход.

Первым шагом будет изменение старых файлов и добавление необходимого действия pragma для деактивации предупреждения в коде.

Второй шаг - создать коммит-ловушку, которая будет отклонять любой зафиксированный файл, содержащий конкретный шаблон прагмы, который отбрасывает все эти «старые» предупреждения.

Это означает, что любой измененный файл должен быть без предупреждения.

Однако, будем откровенны, разработчики всегда находят способы игры в систему.

Answer 6

Если вы собираетесь вносить изменения в код в результате нового более строгого уровня предупреждения, напишите адекватных тестов, которые защищают от появления новых проблем / ошибок. Напишите тесты, используя новый уровень предупреждения. Сделайте это до того, как начнете изменять кодовую базу и проверять правильность работы. Затем вы можете повторно запустить обновленный код для того же теста.