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

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

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

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

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

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

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


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

>
>
Дискуссия о статическом анализе кода

Дискуссия о статическом анализе кода

05 Дек 2017

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

0545_Detailed_Reply_ru/image1.png

Комментарии

Комментарии написаны на русском языке к статье "Передаю привет разработчикам компании Yandex". Первый находится здесь. Процитирую его:

Все эти анализаторы кроме пользы добавляют гемор в виде замедления билда, ложных срабатываний, информационного шума и ложного чувства безопасности. Для себя я решил, что профессионалам чем меньше таких тулзов тем лучше — гемор легко перевешивает пользу. А нубасам такое тоже особо не поможет — им бы учиться писать юнит тесты, а не тратить время на затыкание варнингов. Возможно, в Яндексе думают так же.

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

Дисклеймер: PVS-Studio я не пробовал.

И есть дополнение:

Не забудьте ещё про ваших реальных конкурентов (не де-юре, а де-факто): динамические анализаторы (ASAN, MSAN, TSAN, UBSAN). У них, конечно, есть беда: срабатывают не так быстро и ресурсов требуют больше. Но зато у них есть и преимущество: если уж *SAN чего-то "такое" у вас при фаззинге нашёл, то отбиваться бесполезно — это ошибка, надо чинить. А со статическим анализатором... всякое бывает.

Так что вам нужно влезть в нишу между встроенным в clang/gcc/msvc анализатором (бесплатно и всегда в наличии) и *SAN'ом (сложно и дорого, но зато ложных срабатываний — почти нуль, любую ошибку можно сразу в багтрекер заносить). Так ли велика эта ниша?

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

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

Анализаторы в основном генерируют отвлекающий внимание шум

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

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

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

Предвижу возражение следующего типа: "Про процент ложных срабатываний вы приукрашиваете. У меня компилятор почти не выдаёт предупреждений, а запуская статический анализатор, я вижу тысячи предупреждений".

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

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

Я немного ушел в сторону от главной мысли, но мне надо было объяснить, что статический анализатор - более мощный инструмент, чем механизм генерации предупреждений в компиляторе.

Так вот, отказаться от статического анализа так же глупо, как выключить все предупреждения компилятора. Вот смотрите, давайте немного перепишем исходный комментарий:

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

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

Если кто-то скажет, что предупреждения компилятора дают ему ложное чувство безопасности, то это проблема говорящего, а не компилятора.

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

Как вы понимаете, всё то же самое относится и к статическому анализу кода. Мы подробно рассмотрели первую часть заблуждений и переходим к следующим.

Новичкам проку от статического анализа нет

А нубасам такое тоже особо не поможет — им бы учиться писать юнит тесты, а не тратить время на затыкание варнингов.

Я согласен с тем, что в первую очередь новички должны изучать язык программирования, учиться отлаживать код, учиться писать юнит-тесты и так далее. Без фундаментальных знаний никакие вспомогательные инструменты не помогут.

Да, наверное, статический анализ не та технология, которой надо уделить внимание в первую очередь. Однако статический анализ - всегда друг, независимо от профессионализма разработчика. Он вполне может быть полезен и студентам, подсказывая им, что с кодом что-то не так, и давая пищу для дальнейшего изучения языка. У нас, кстати, есть интересная статья на тему проверки студенческого кода: "О зле, случайно призванном учениками магов".

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

Примечание. Юнит-тесты, кстати, тоже не панацея, и статический анализатор дополняет эту методологию, а не конкурирует с ней. См. статью "Как статический анализ дополняет TDD".

Можно прогонять статический анализатор перед релизом

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

Это совершенно неправильный способ использования анализатора! Хуже только вариант, когда статический анализ вообще не используется или используется раз в 5 лет.

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

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

Здесь вновь уместна аналогия с предупреждениями компилятора. Допустим, полностью отключаются предупреждения, и 3 месяца разрабатывается проект. А затем, за день до релиза, все эти предупреждения компилятора включаются. Согласитесь, это глупость какая-то.

Ещё здесь будет уместно предложить познакомиться со статьёй коллеги, посвященной бестолковости разовых запусков анализатора: "Философия статического анализа кода: у нас 100 программистов, анализатор нашел мало ошибок, он бесполезен?".

Динамический анализ - конкурент статическому анализу

Не забудьте ещё про ваших реальных конкурентов (не де-юре, а де-факто): динамические анализаторы (ASAN, MSAN, TSAN, UBSAN). У них, конечно, есть беда: срабатывают не так быстро и ресурсов требуют больше. Но зато у них есть и преимущество: если уж *SAN чего-то "такое" у вас при фаззинге нашёл, то отбиваться бесполезно — это ошибка, надо чинить. А со статическим анализатором... всякое бывает.

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

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

Мы не рассматриваем динамические анализаторы как конкурентов, так как профессиональные программисты не ставят вопрос "Что выбрать?". Они используют обе эти технологии, ведь и та, и та помогает ответить на вопрос: "Что я ещё могу сделать для повышения качества кода?".

Примечание

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

Сложно влезть в нишу между компиляторами и динамическими анализаторами

Так что вам нужно влезть в нишу между встроенным в clang/gcc/msvc анализатором (бесплатно и всегда в наличии) и *SAN'ом (сложно и дорого, но зато ложных срабатываний — почти нуль, любую ошибку можно сразу в багтрекер заносить). Так ли велика эта ниша?

Ниша широка, и в ней замечательно помещается не только анализатор PVS-Studio, но и инструменты множества других компаний, таких как SonarSource, Synopsys (бывший Coverity), Gimpel Software, Rogue Wave Software и так далее.

Почему ниша широка? Ответ прост: озвученное в комментарии никак не ограничивает статические анализаторы кода. У одной границы поставлены динамические анализаторы. Но, как выяснили ранее, там нет конкуренции, а дружественный симбиоз.

У другой границы - компиляторы. Да, компиляторы становятся всё умнее. Однако инструменты статического анализа тоже не стоят на месте и быстро развиваются.

Для скептиков у меня есть ряд публикаций, в которых я демонстрирую, что PVS-Studio легко находит ошибки в этих компиляторах:

PVS-Studio я не пробовал

Зря, попробуйте :). Многим нравится, и они становятся нашими клиентами.

Причём попробовать PVS-Studio очень просто. Зайдите на страницу продукта и скачайте демонстрационную версию.

По любым возникающим вопросам смело пишите в поддержку. Поможем выполнить анализ большого проекта, разобраться с предупреждениями, проконсультируем про варианты лицензирования.

Всем спасибо за внимание и желаю безбажного кода.

Популярные статьи по теме
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

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

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

Дата: 20 Мар 2017

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

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

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

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

Дата: 30 Янв 2019

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

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
PVS-Studio для Java

Дата: 17 Янв 2019

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

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

Дата: 19 Май 2017

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

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

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

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

Дата: 31 Май 2014

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

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

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

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

Дата: 16 Окт 2017

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

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

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

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

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