Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Что поражает меня при разработке статич…

Что поражает меня при разработке статического анализатора кода

28 Ноя 2011

При разработке любого инструмента для программистов, будь то компилятор, статический анализатор или что-то еще естественно используются тестовые проекты, на которых этот инструмент постоянно гоняется. Например, при разработке статического анализатора мы прогоняем его на базе из 70 реальных проектах. Это позволяет быть уверенным, что все в порядке и ничего не отломалось. Кроме того, когда мы разрабатываем новые правила диагностики ошибок, после прогона мы видим, в каких фрагментах кода выявлены новые ошибки. Все логично и очевидно. Так почему же такой заголовок?

Дело в том, что тестовая база проектов – явление довольно устоявшееся у нас. Давно уже написаны статьи про ошибки в eMule, WinMerge, TortoiseSVN... И, казалось бы, что все эти тестовые проекты изучены нами вдоль и поперек. А получается, что нет. Ведь вновь и вновь в коде удается найти новые забавные фрагменты кода.

Вот пример:

void CIrcMain::Disconnect(bool bIsShuttingDown)
{
 m_pIrcSocket->Close();
 if (m_pIrcSocket != NULL)
  delete m_pIrcSocket;
}

Код, в общем-то, может даже и работает. В некоторых случаях. Иногда. Когда m_pIrcSocket не NULL. Правда автор не уверен, что m_pIrcSocket всегда будет не NULL и добавил проверку. Но ПОСЛЕ использования. Соответственно, если данный код будет выполнен при m_pIrcSocket, то получим падение, хотя и проверка на NULL есть.

Еще один пример точного такого же плана:

  if (!frmExist)
  {
    frmExist = 
       tag->Find(ID3FID_SYNCEDLYRICS, ID3FN_DESCRIPTION, desc);
  }

  if (NULL != tag && NULL != data)
  {

Здесь сначала разыменовывается переменная tag и лишь затем она проверяется. Вопрос все тот же, если автор уверен, что tag не NULL, то зачем он проверяет, а если не уверен, то проверка должна быть раньше.

Так вот, возвращаясь к вопросу, вынесенному в заголовок заметки. Что поражает меня – так это то, что хотя мы много ошибок в коде УЖЕ нашли в наших тестовых проектах, мы все продолжаем и продолжаем находить новые ошибки. С одной стороны это логично, ведь анализатор развивается и соответственно находит что-то новое. С другой – поразительно. Ведь, казалось бы, мы уже столько смотрели на эти тестовые проекты и неужели в них можно найти что-то новое. Оказывается можно.

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

Популярные статьи по теме
Обрабатывать ли в PVS-Studio вывод других инструментов?

Дата: 26 Май 2022

Автор: Андрей Карпов

Анализатор PVS-Studio умеет "схлопывать" повторяющиеся предупреждения. Предоставляет возможность задать baseline, что позволяет легко внедрять статический анализ в legacy-проекты. Стоит ли предостави…
15000 ошибок в открытых проектах

Дата: 24 Май 2022

Автор: Андрей Карпов

Количество багов в нашей коллекции перевалило за отметку 15000. Именно такое количество ошибок обнаружила команда PVS-Studio в различных открытых проектах. Особенно интересно, что это всего лишь побо…
Комментарии в коде как вид искусства

Дата: 04 Май 2022

Автор: Сергей Хренов

Приветствую всех программистов, а также сочувствующих. Кто из нас хотя бы раз в жизни не оставлял комментарии в коде? Был ли это ваш код, а может, чужой? Что за комментарии вы написали: полезные или …
Visual Studio 2022 стильно и свежо. История о её поддержке в PVS-Studio

Дата: 15 Фев 2022

Автор: Николай Миронов

Кажется, анонс Visual Studio 2022 был только недавно, и вот она уже вышла. Это означало ровно одно – поддержать данную IDE нужно в ближайшем релизе PVS-Studio. О том, с какими сложностями пришлось ст…
Лучшие срабатывания статического анализатора

Дата: 29 Окт 2021

Автор: Максим Звягинцев

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

Комментарии (0)

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