Для получения триального ключа
заполните форму ниже
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. В нём я регулярно публикую ссылки на интересные статьи по тематикам: Си/Си++, статический анализ кода, оптимизация, прочие интересное о программировании.

Последние статьи:

Опрос:

Популярные статьи по теме
Межмодульный анализ C и C++ проектов в деталях. Часть 2

Дата: 14 Июл 2022

Автор: Олег Лысый

В первой части статьи мы рассматривали основы теории компиляции C и C++ проектов, в частности особое внимание уделили алгоритмам компоновки и оптимизациям. Во второй части мы погрузимся глубже и пока…
Межмодульный анализ C и C++ проектов в деталях. Часть 1

Дата: 08 Июл 2022

Автор: Олег Лысый

Начиная с PVS-Studio 7.14, для C и C++ анализатора появилась поддержка межмодульного анализа. В этой статье, которая будет состоять из двух частей, мы расскажем, как устроены похожие механизмы в комп…
Как внедрить статический анализатор кода в legacy проект и не демотивировать команду

Дата: 20 Июн 2020

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

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

Дата: 08 Июн 2020

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

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

Дата: 16 Янв 2020

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

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

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

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо