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

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

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

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

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

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

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


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

>
>
Ощущения, которые подтвердились числами

Ощущения, которые подтвердились числами

30 Авг 2012

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

Во многих из прочитанных мною статей делается такое предположение. Если в проекте размером N строк кода, найдено 2 ошибки, то в полноценном проекте размером в N*100 строк, можно найти только 200 ошибок. И из этого делается вывод, что статический анализ, это конечно хорошо, но не замечательно. Слишком мало ошибок. Лучше развивать другие методики поиска дефектов.

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

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

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

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

Первый недочёт всех этих исследований очевиден. Забывают, что берётся рабочая отлаженная версия какого-то проекта. Многие из ошибок, которые можно было бы быстро найти статическим анализом, искались медленно и печально. Они обнаруживались во время тестирования или после жалоб пользователей. То есть забыто, что статический анализ это инструмент постоянного, а не разового применения. Ведь программисты регулярно смотрят на Warnings, выдаваемые компилятором, а не раз в год.

Со вторым недочётом в исследованиях всё обстоит сложнее и интереснее. У меня было чёткое ощущение, что нельзя равнозначно оценивать маленькие и большие проекты. Пусть студент написал за 5 дней хороший проект для курсовой работы, содержащий 1000 строк кода. Я уверен, что за 500 дней он не сможет написать хорошее коммерческое приложение, объемом в 100 000 строк кода. Ему помешает рост сложности. Чем больше становится программа, тем сложнее добавлять в неё новый функционал, тем больше требуется её тестировать и больше возиться с ошибками.

В общем, ощущение было, но сформулировать мне его никак не удавалось. Неожиданно мне на помощь пришёл один из сотрудников. Изучая книгу Стива Макконнелла "Совершенный код" он заметил в ней интересную табличку. А я то, про неё и забыл. Это табличка всё сразу расставляет на свои места!

Конечно же, рассматривая маленькие проекты, некорректно оценивать количество ошибок в больших! В них разная плотность ошибок!

Чем больше проект, тем больше ошибок на 1000 строк кода он содержит. Взгляните на эту замечательную таблицу:

0158_Feelings_ru/image1.png

Таблица 1. Размер проекта и типичная плотность ошибок. В книге указаны источники данных: "Program Quality and Programmer Productivity" (Jones, 1977), "Estimating Software Costs" (Jones, 1998).

Чтобы было легче воспринимать данные, построим графики.

0158_Feelings_ru/image2.png

График 1. Типичная плотность ошибок в проекте. Синий - максимальное количество. Красный - среднее количество. Зелёный - наименьшее количество.

Думаю, рассматривая эти графики, становится понятно, что зависимость не линейна. Чем больше проект, тем легче в нём допустить ошибку.

Конечно, статический анализатор выявляет не все ошибки. Однако чем больше проект, тем более эффективен статический анализатор. А ещё более он эффективен, если используется регулярно.

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

Да, это сложнее, но вы получите правильное представление о возможностях. Например, как один из авторов PVS-Studio, могу обещать, что мы стараемся помочь всем, кто к нам обращается. Если в процессе изучения PVS-Studio что-то не будет получаться, напишите нам. Часто многие проблемы удается решить правильной настройкой инструмента.

P.S.

Приглашаю присоединиться к моему твиттеру @Code_Analysis. В нём я регулярно публикую ссылки на интересные статьи по тематикам: Си/Си++, статический анализ кода, оптимизация, прочие интересное о программировании.

Популярные статьи по теме
Как внедрить статический анализатор кода в legacy проект и не демотивировать команду

Дата: 20 Июн 2020

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

Попробовать статический анализатор кода легко. А вот, чтобы внедрить его, особенно в разработку большого старого проекта, потребуется умение. При неправильном подходе анализатор может добавить работы…
Анализатор PVS-Studio на сайте godbolt.org (Compiler Explorer) и предостережение

Дата: 08 Июн 2020

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

Мы добавили возможность экспериментировать со статическим анализатором кода PVS-Studio на сайте godbolt.org (Compiler Explorer). Поддерживается анализ C и C++ кода. Уверены, что это интересный и очен…
Использование машинного обучения в статическом анализе исходного кода программ

Дата: 16 Янв 2020

Автор: Андрей Карпов, Виктория Ханиева

Машинное обучение плотно укоренилось в различных сферах деятельности людей: от распознавания речи до медицинской диагностики. Популярность этого подхода столь велика, что его пытаются использовать ве…
Зачем нужен динамический анализ кода, если есть статический?

Дата: 24 Июл 2019

Автор: Илья Гайнулин

Для проверки качества программного обеспечения приходится применять много разных инструментов. В частности, к ним относятся инструменты статического и динамического анализа. В данной статье мы попроб…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

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

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

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

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