Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Вебинар: Базовые сценарии интеграции SAST решения в legacy-проект на примере PVS-Studio - 18.04
Данная статья предназначена для всех начинающих пользователей статического анализатора кода PVS-Studio в среде Visual Studio. В статье рассмотрен базовый сценарий использования анализатора. Освоив материал этой статьи, разработчик сможет легко начать работу с анализатором, а затем по необходимости углубить свои знания с помощью PVS-Studio документации.
Начиная с версии PVS-Studio 6.00, у разработчиков есть возможность проверить с помощью анализатора PVS-Studio не только C/С++ код, но и C# код. Условия лицензирования остаются прежними - вы покупаете/продлеваете лицензию PVS-Studio, но теперь можете использовать PVS-Studio сразу для 3-х языков программирования С/C++/C#.
Часто, впервые проверив свой код с помощью анализатора, разработчик не знает, что делать со всем тем обилием ошибок, которые нашел анализатор. По проекту приходят новые задачи, а быстро исправить найденные анализатором проблемы не получается. Разработчик хочет отложить текущие предупреждения анализатора и начать анализировать новый написанный код, чтобы сразу получать подсказки от анализатора о возможных проблемах. Еще одно разумное требование к анализатору - иметь возможность вернуться к ошибкам, найденным в старом коде. Рассмотрим реализацию такого сценария использования PVS-Studio на примере анализа C# проекта.
Рассмотрим сценарий работы с PVS-Studio на примере проекта Sharp Developer. Ошибки, найденные в этом проекте, мы уже обсудили в рамках предыдущей статьи.
PVS-Studio анализатор встраивается в среду Visual Studio при инсталляции. Использование анализатора в Visual Studio - это самый простой способ работы с ним.
При первом использовании анализатора мы рекомендуем проанализировать проект целиком. Для этого выберете в пункте меню PVS-Studio > Check > Solution.
Рисунок 1. Проверка всего решения.
В рамках проекта Sharp Developer анализатор обнаружил 20 предупреждения высокой важности, 32 - средней и 182 - низкой. По умолчанию, программист видит предупреждения только высокой важности, именно с них мы рекомендуем начинать, а затем переходить к предупреждениям низкой важности.
Рисунок 2. Окно с диагностическими сообщениями (нажмите на картинку для увеличения).
Разработчик и рад бы сразу начать исправлять ошибки, но уже сегодня он должен работать над новой задачей, а разбор текущих предупреждений необходимо отложить. Анализатор позволяет воплотить такой сценарий. Достаточно подавить предупреждения и начать использовать анализатор для нового кода, а позже вернуться к предупреждениям в старом коде.
Для этого в рамках анализатора нужно сделать 2 действия:
Чтобы временно подавить предупреждения, выберите пункт меню "Suppress Messages".
Рисунок 3. Массовая разметка предупреждений, как неинтересных в данный момент времени.
Затем в новом окне нажмите "Suppress Current Messages".
Все предупреждения из одного проекта будут записаны в xml формате и сохранены с расширением ".suppress" в папке проекта. Эти предупреждения не будут показываться в окне PVS-Studio в Visual Studio, если вы отдельно не отметили это в настройках.
Разработчик подавил все предупреждения, и он видит окно PVS-Studio без ошибок. Следующий шаг начать получать предупреждения анализатора только для нового кода.
По умолчанию для того чтобы увидеть новые ошибки, после сборки проекта с новым кодом вам нужно будет перезапустить анализатор для проекта или решения (solution). Это избыточный вариант. Значительно более элегантное решение - воспользоваться инкрементальным анализом и проверять новый код с помощью PVS-Studio сразу после сборки проекта. Чтобы подключить инкрементальный анализ выберете в пункте меню "Analysis after Build".
Рисунок 4. Включение/выключение автоматической проверки файлов после компиляции.
Посмотрим как это работает. Предположим мы написали простой класс:
class TestAnalyzer
{
public void Logging(DateTime dateTime)
{
System.IO.File.WriteAllText(
@"S:\path\to\file.log",
String.Format("Logging time: {1}h {2}m",
dateTime.Hour,
dateTime.Minute));
}
private void OnLoad()
{
Console.WriteLine("Event!");
Logging(DateTime.Now);
}
private void OnClose()
{
Console.WriteLine("Event!");
Logging(DateTime.Now);
}
}Собрали его. Анализатор покажет 2 предупреждения.
Рисунок 5. Пример работы инкрементального анализа.
Давайте посмотрим как можно поработать с этими предупреждениями.
Реальная ошибка
Предупреждение V3025 является ошибкой. Рассмотрим ее суть. Разработчик пытается обратиться к параметру dateTime.Minute, используя индекс 2, но нумерация аргументов другая -dateTime.Hour - индекс 0, dateTime.Minute - индекс 1, поэтому необходимо использовать индексы 0 и 1 при обращении к параметрам. Исправим проблему заменой строки:
System.IO.File.WriteAllText(
@"S:\path\to\file.log",
String.Format("Logging time: {1}h {2}m",
dateTime.Hour,
dateTime.Minute));На строку
System.IO.File.WriteAllText(
@"S:\path\to\file.log",
String.Format("Logging time: {0}h {1}m",
dateTime.Hour,
dateTime.Minute));Ложное срабатывание
Во втором случае анализатор слишком придирается к разработчику и считает, что не может быть одной и той же логики в обработчике событий OnLoad и OnClose . Мы понимаем, что конкретно в нашем случае это нормально, и решаем что это ложное срабатывание. Для того чтобы пометить предупреждение как ложное срабатывание, достаточно кликнуть по нему правой кнопкой мыши и выбрать "Mark selected messages as False Alarms"
Рисунок 6. Подавление конкретного предупреждения путём добавления специального комментария в код.
После этого анализатор добавит к строке, для которой он вывел предупреждение, комментарий вида "//-V3013". Больше он не будет выдавать предупреждение V3013 на эту строку кода. Подробнее про ложные срабатывания и их обработку можно в статье "Подавление ложных предупреждений".
Следует отметить, что в рамках анализатора используется продвинутый алгоритм определения нового кода. Если вы не будете создавать новый класс, а будете что-то менять в старом коде, анализатор сможет определить необходимость перепроверки такого файла. Больше про это можно прочитать в документации.
И вот у разработчика выдалось время, и он хочет начать работать с предупреждениями в старом коде. Нет ничего проще. Нужно выбрать Suppress Messages в меню, а затем выбрать для какого проекта показать предупреждения, например, для ICSSharpCode.SharpDevelop.
Рисунок 7. Удаление проекта из списка.
Затем нужно нажать кнопку "Delete Selected Files". Файл NameOfTheProject.suppress из папки проекта будет удален физически, и анализатор больше не будет скрывать найденные предупреждения в проекте. Чтобы увидеть предупреждения, достаточно запустить анализатор для проекта, в котором вы отменили подавление предупреждений.
Рисунок 8. Проверка одного выбранного проекта.
После запуска вы увидите предупреждения анализатора для данного проекта. И сможете с ними начать работать.
В статье рассматривается процесс работы с анализатором с точки зрения отдельного разработчика. Мы рекомендуем придерживаться этого процесса. А еще советуем запускать проверку исходного кода на сервере. Разработчик может пропустить сообщение анализатора или забыть его обработать. Подробнее об этом можно почитать в документации в статье:
Надеюсь у вас не осталось вопросов по пользованию анализатором! Если все же они есть, напишите на support@viva64.com, мы с удовольствием ответим.
0
0
0
0