Вопрос или проблема
Наши проекты имеют <TreatWarningsAsErrors> включённым, и мы в целом можем справляться с ними, не подавляя. Однако недавно мы столкнулись с ситуацией, когда предупреждение нельзя исправить из-за обстоятельств, находящихся вне нашего контроля:
if (CheckForHigherVersion())
{
// Исправления пока нет, ждем будущего обновления
CallObsoleteFunction(); // Предупреждение здесь
}
else
{
CallObsoleteFunction(); // Это нормально
}
Я знаю, что мы можем использовать WarningsNotAsErrors, NoWarn или #pragma warning disable. Проблема с ними в том, что мы действительно хотим вернуться к ним позже, чтобы исправить их, поэтому лучше, чтобы мы всё ещё видели предупреждение при компиляции на данный момент.
Использование чего-то вроде #warning fix this later тоже не работает, потому что это всё равно трактуется как ошибка.
На данный момент // TODO: fix this later кажется единственным, что работает для нас, но это не так уж “в лицо”, как предупреждение. Есть ли лучшее решение для этого сценария?
Ответ или решение
Ситуация, с которой вы столкнулись, когда использование <TreatWarningsAsErrors> вызывает затруднения из-за определённого предупреждения, которое вы не можете устранить, действительно может вызывать беспокойство. Ваша цель — сохранять предупреждения видимыми, чтобы у вас была возможность вернуться к ним позже. Давайте рассмотрим несколько возможных решений данной проблемы.
1. Использование #pragma warning disable с пометкой TODO
Хотя вы упомянули #pragma warning disable, это решением может стать временное отключение конкретного предупреждения, при этом с добавлением комментария, например:
#pragma warning disable CS0618 // Отключаем предупреждение об устаревшей функции
CallObsoleteFunction(); // TODO: исправить это позже
#pragma warning restore CS0618 // Восстанавливаем предупреждениеЭто позволит вам отключить предупреждение временно, но оставить заметку о том, что оно всё еще требует внимания. Такой подход сохраняет ясность для других разработчиков.
2. Использование кастомного класса для логирования
Если предупреждение связано с устаревшей функцией, вы можете рассмотреть возможность создания собственных обёрток или классов, которые обрабатывают устаревшие вызовы. Например:
public static void CallSafeObsoleteFunction()
{
CallObsoleteFunction();
LogWarning("Используется устаревшая функция, исправить позже");
}Здесь можно будет логировать предупреждения в файл или систему мониторинга, что позволяет отслеживать их без возникновения ошибок компиляции.
3. Применение комментариев TODO
Вы оказались правы в использовании комментариев // TODO: fix this later. Хотя эти комментарии могут показаться менее заметными, вы можете применять специальные инструменты для отслеживания таких комментариев. Многие IDE выделяют TODO комментарии и позволяют вам формировать списки задач, что даёт возможность эффективно управлять будущими изменениями.
4. Ведение списка предупреждений
Составьте документ или задачу в трекере для всех предупреждений, которые вы не можете исправить немедленно. Используйте уникальные теги или метки, чтобы фильтровать их. Это поможет вам в дальнейшем не забыть о необходимости исправления этих мест.
5. Рассмотрите использование внешних инструментов
Если ваша команда активно использует системы CI/CD, возможно, стоит интегрировать инструмент статического анализа кода, который сможет отслеживать предупреждения и ошибки, а также выстраивать отчёты об их наличии в проекте.
Заключение
Хотя использование опции <TreatWarningsAsErrors> является хорошей практикой, порой возникают обстоятельства, когда нужны дополнительные подходы для управления предупреждениями. Необходимо учитывать, что, хотя выражение и фиксирование объектов кода является важным, ведение четкого учета нерешённых проблем также критично. Подходите к этой задаче комплексно и используйте инструменты, на которые можете полагаться для сохранения фиксации задач.