Мифы о статическом анализе. Миф четвёртый – программисты хотят добавлять свои правила в статический анализатор

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



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

Миф четвертый: "Статический анализатор должен иметь возможность добавлять пользовательские правила. Программисты хотят добавлять свои собственные правила."

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

Я всегда отвечал, что реализация собственных правил это не то, что хотят программисты. И не видел другой альтернативы, кроме реализации диагностик разработчиками анализатора по просьбам программистов (статья на эту тему). Недавно я плотно пообщался с Дмитрием Петуниным. Он является руководителем отдела тестирования компиляторов и разработки инструментов верификации программ Intel. Он расширил мое понимание этой темы и озвучил идею, о которой я думал, но так и не сформулировал в конечном варианте.

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

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

Программисты действительно хотят искать некоторые паттерны/ошибки в своём коде. Им это действительно нужно. Например, человеку нужно найти вся явные приведения от типа int к float. Эту задачу нельзя решить, используя такие инструменты, как grep. Ведь в конструкции вида "float(P->FOO())" неизвестно какой тип вернет функция FOO(). В этот момент программист и приходит к выводу, что он может реализовать поиск таких конструкций, добавив свою проверку в статическом анализаторе.

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

Именно поэтому и я, и Дмитрий не поддерживаем идеи предоставлять пользователю API для работы с анализатором. Это крайне сложная задача с точки зрения разработки. И при этом от неё человек вряд ли будет использовать более 1%. Нерационально. Разработчику проще и дешевле реализовывать пожелания пользователей, чем создавать сложный API для модулей расширения или создавать специальный язык описания правил.

Читатель заметит: "тогда откройте в API только 1% от функциональности и все будут довольны". Да, всё правильно. Но смотрите, как сместился акцент. От разработки своих правил мы пришли к тому, что на самом деле достаточен инструмент, схожий с grep, но обладающий некоторой дополнительной информацией о коде программы.

Пока такого инструмента нет. Если вы хотите решить какую-то задачу, то можете написать мне, и мы постараемся реализовать её в анализаторе PVS-Studio. Например, недавно мы как раз реализовывали несколько пожеланий по поиску явных приведений типов: V2003, V2004, V2005. Воплощать в жизнь такие пожелания нам намного проще, чем создавать и поддерживать открытый интерфейс. Проще это и самим пользователям.

Кстати, возможно такой инструмент со временем появится в рамках Intel C++. Дмитрий Петунин говорил, что они обсуждали возможность создания grep-подобного инструмента, обладающего знаниями о структуре кода и типах переменных. Но это обсуждалось абстрактно. Я не знаю, планируется в действительности создать такое или нет.



Найдите ошибки в своем C, C++, C# и Java коде

Предлагаем попробовать проверить код вашего проекта с помощью анализатора кода PVS-Studio. Одна найденная в нём ошибка скажет вам о пользе методологии статического анализа кода больше, чем десяток статей.

goto PVS-Studio;

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


Найденные ошибки

Проверено проектов
355
Собрано ошибок
13 303

А ты совершаешь ошибки в коде?

Проверь с помощью
PVS-Studio

Статический анализ
кода для C, C++, C#
и Java

goto PVS-Studio;