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

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

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

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

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

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

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


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

Популярные статьи по теме
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

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

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

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

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

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

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
PVS-Studio для Java

Дата: 17 Янв 2019

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

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

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

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

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

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

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

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
Любите статический анализ кода!

Дата: 16 Окт 2017

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

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

Дата: 21 Ноя 2018

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

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

Дата: 31 Июл 2017

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

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…

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

Следующие комментарии

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