Команда PVS-Studio и наш продукт делают большой вклад в развитие качества программного обеспечения. Причем, помимо явного обнаружения ошибок в закрытых и открытых проектах, происходит косвенный вклад в развитие компиляторов и других инструментов анализа кода. Нам приятно, что мы иногда являемся законодателями мод и мы решили посвятить этому небольшую заметку в нашем блоге.
PVS-Studio — это статический анализатор для выявления ошибок и потенциальных уязвимостей в исходном коде программ, написанных на языках С, C++, C# и Java.
Для популяризации методологии статического анализа кода и нашего инструмента мы пишем заметки о проверке различных открытых проектов. В том числе, мы время от времени проверяем различные компиляторы. Например, мы проверяли и находили ошибки в таких проектах, как: GCC, LLVM, PascalABC.NET, Roslyn.
Мы уже не раз замечали интересный факт. Как только мы проверяем, скажем, LLVM или GCC, то через один-два релиза в этих компиляторах появляется пара новых диагностик, нацеленных на выявление ошибок, которые удалось найти PVS-Studio в их коде :). К сожалению, мы не догадались выписывать даты и ссылки на соответствующие нововведения, поэтому вам придётся поверить здесь нам на слово. Различные C++ компиляторы заимствуют некоторые наши диагностики, и мы считаем, что это совершенно нормально, правильно и полезно!
Помимо C++ компиляторов теперь к заимствованию диагностик подключились и C# анализаторы. Это значит, что C# анализатор, реализованный в PVS-Studio, становится другим образцом для подражания! Осознавать это приятно и здорово.
В данном случае я могу зафиксировать, можно сказать, в реальном времени, как это происходит. 13 августа 2019 года мы опубликовали большую статью, посвященную проверке .NET Core Libraries (CoreFX). Помимо всего прочего, в этой статье мы описали паттерн ошибки, связанный с использованием интерполированных строк (см. диагностику V3138). Разработчики CoreFX с интересом отнеслись к нашей публикации и приступили к исправлению найденных нами ошибок. И уже 14 августа они добрались до найденных нами ошибок, связанных с этими самыми интерполированными строками: Fix a few missing $s for string interpolation in tracing.
Теперь самое интересное. В этот же самый день в проекте Roslyn Analyzers появилась задача по реализации новой диагностики "New rule: Interpolated strings that are missing the $ special character #2767", связанная как раз с ошибками, исправленными в CoreFX.
Нам приятно, что наш труд оказался полезен разработчикам CoreFX и что наши диагностики стали примером для подражания у разработчиков Roslyn Analyzers. Немного жаль, что нигде в дискуссии не упоминается инструмент PVS-Studio. Получается, что как будто они сами нашли эти ошибки и сами придумали сделать диагностики. Нам бы, конечно, польстило, если бы нас упоминали как первоисточник. Ну да ладно.
Почему мы решили написать про всё это? Нам очень приятно, и мы даже немного гордимся собой! Изучая наш опыт, другие компиляторы реализуют новые диагностики, что повышает качество разрабатываемого программного обеспечения в целом. Я понимаю, что не только мы влияем на развитие возможностей компиляторов по поиску ошибок. Однако нам приятно осознавать, что мы вносим вклад в этот процесс.
Беспокоит ли нас, что другие инструменты постепенно учатся находить те же ошибки, что и PVS-Studio? Нет. Наш инструмент как раз существует и продаётся по той причине, что мы всегда опережаем возможности компиляторов. Наша задача — всегда оставаться впереди. Осознание же того, что нас постоянно догоняют, не позволяет нам расслабляться, и это идёт всем на пользу. Помимо этого, надо понимать, что PVS-Studio это не только предупреждения, но и:
- Быстрая качественная поддержка (на письма отвечают только программисты);
- Интеграция с Visual Studio, IntelliJ IDEA, SonarQube, Jenkins, IncrediBuild;
- Возможность использования как локально, так и в облаке (Docker, Travis CI);
- Инструменты интеграции анализа в большие старые проекты (Mass Suppression);
- Подробная документация с примерами по каждому паттерну ошибки;
- Механизм рассылки писем разработчикам (BlameNotifier);
- Отслеживание запусков компилятора (Compiler Monitoring);
- И так далее.
Спасибо за внимание. Надеюсь, вы порадовались вместе с нами за PVS-Studio. И попробуйте наш анализатор для непрерывного контроля качества кода ваших проектов.
Дополнительные ссылки:
- График развития диагностических возможностей в PVS-Studio.
- Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. PVS-Studio: Engine of Progress.
Комментарии (22)
datacompboy
20.08.2019 19:00+1Поздравляю! Учитывая, что это только одна из :)) логично что вам особо не из-за чего беспокоиться.
p.s.: но двигателем прогресса вроде является ЖРДМТ 11Д428А-16?
creat0r
20.08.2019 20:43+8Пару месяцев назад в кулуарах одного тематического barcamp'а в Германии один из участников с энтузиазмом рассказывал мне про a very good source code static analyzer.
Guess what, the world is a very small place, 'cause they are from my home town — ответил я.
Вы очень хорошо известны в мире и котируетесь среди лучших. Моё почтение :)
alan008
20.08.2019 23:33Некоторые крупные Open Source проекты вы проверяли по несколько раз. Нет ли идеи ранжировать эти проекты по количеству коммитов или изменённых строк кода с момента предыдущей проверки и проверить те, которые больше всего изменялись, ещё раз?
Andrey2008 Автор
20.08.2019 23:40Мысль интересная и такое имело бы смысл сделать в случае дефицита проектов. Но их проверяй не хочу :). Вот сейчас, пока пауза между конференциями, команда выкатывает одну статью за одной. Тем более, частая перепроверка одних и тех же проектов может быть неинтересна читателям. А вот, например, не имеющая практического смысла, «историческая» статья "К тридцатилетию первого C++ компилятора: ищем ошибки в Cfront" очень даже нравится читателям и внесла разнообразие.
alan008
20.08.2019 23:37И если уж вы прошлись по всем популярным языкам (C++, Java, C#) вы просто обязаны добавить хоть какой-то анализатор для Python, благо в нем тоже хватает способов выстрелить себе в ногу и полно Open Source проектов на нем. Это возведет вас просто на вершину всех анализаторов.
Andrey2008 Автор
20.08.2019 23:45Это возведет вас просто на вершину всех анализаторов.
Спасибо. :)
Мы развиваемся за счёт собственных средств и пока не накопили ресурсов для следующего рывка. Каждый новый язык приводит к росту команды, усложнению инфраструктуры и так далее. Т.е. очень быстро поглощаются деньги. А отдача от начала освоения нового направления будет не быстро. А так, теоретически, мы давно считаем, что Python и/или PHP лишними не будут.alan008
20.08.2019 23:59+1Тоже хотел было сначала предложить PHP, но все таки это не то. PHP — это только веб-бэкенд, причём в проектах чаще всего низкого уровня качества, где всем пофиг на ошибки, даже если они есть (а они там точно есть). А вот Python — это все что угодно, включая как фреймворки для веб бэкендов, так и математические расчёты (NumPy), нейросети, ORM и кучу всякой всячины.
gasizdat
21.08.2019 08:24+2на письма отвечают только программисты
Сочувствую вам, коллеги. Держитесь!
EvgeniyRyzhkov
21.08.2019 09:30Я сочувствую тем программистам, которые никогда не общаются со своими пользователями и клиентами. Такие программисты живут в выдуманном мире без обратной связи. Они не понимают проблем своих пользователей, а значит не могут их решить. И никогда не испытывают чувство удовлетворения от того, что ты помог человеку.
Приносить пользу людям — это круто. А когда конкретные люди тебя за это еще и благодарят, то это приятно вдвойне.
Любите своих пользователей, никогда не избегайте их и всегда старайтесь пересечься на конференциях. Это сохранит ваш душевный баланс.MooNDeaR
21.08.2019 20:40Это смотря кто твой пользователь :) Если это другие программисты, то еще куда ни шло конечно. А вот если это какой-нибудь? бухгалтер/директор в пенсионном фонде, то ну его нафиг)
SvyatoslavMC
21.08.2019 12:48+1Тем не менее, это очень ценится программистами на другой стороне. Всё понятно и решается быстро.
А вот почему. Вы когда-нибудь пробовали сообщить о баге в крупную компанию? За последний месяц я отписал 3 бага в VK. И каждый раз мне пишут, что «такое бывает из-за вирусов, нате ссылку для проверки компьютера». Это так бесит, что по некоторым вопросам я просто забивал на продолжение общения. Хотя баг налицо, но связи с компетентными людьми нет.gasizdat
21.08.2019 13:33IT компания может быть клиенто-ориентированной и при этом программисты могут не работать на первой линии техподдержки. Все зависит от правильности распределения ролей в команде и желания налаживать производственные процессы.
В любом случае, если отвлекать прогеров на общение с клиентами, то когда им код писать? Я уж не говорю об эмоциональных качествах (типа интровертности, обычной для программистов), которые могут не позволить нормально совмещать состояние потока и перманентное общение с неограниченным кругом лиц.SvyatoslavMC
21.08.2019 14:00+1Мы наладили этот процесс, чтобы всем было комфортно, но наша аудитория — программисты. Что посоветовать VK, Сберу и т.д. я не знаю. Клиенто-ориентированность — не ключевой фактор.Те же VK и Сбер максимально хотят Вам помочь, но прийти к ним с технической проблемой равносильно битью головой об стену.
Я вижу решение в разделении технической и пользовательской поддержки для таких компаний. Но пример привести не могу, т.к. не встречал подобного.
Ещё неприятный пример был (с хеппи эндом), когда мне надо было донести до хостера Rutube, где у них косяк. Кроме простых видосиков, услугами этого хостера пользуются разные компании для своих нужд. Так, я 3 месяца искал связи хоть с кем-нибудь. В итоге мне дали E-mail разработчиков и проблема была исправлена за 2 часа. Это я ещё был физиком в этой ситуации, когда такое происходит в B2B бизнесе, то это печаль.
mirypoko
21.08.2019 14:24Имхо было бы круто, если бы PVS-Studio был встроен в github и аналогичные сервисы по платной подписке. Кто-то сделал комит — сразу прилетает предупреждение о потенциальных проблемах.
Andrey2008 Автор
21.08.2019 14:31Мы движемся в эту стороны, но в каком виде это будет оформляться, пока говорить рано. См. ?PVS-Studio идёт в облака – запуск анализа на Travis CI.
SemenPV
А как с вашей стороны? Есть ли примеры того как вы были вдохвлены конкурирующим продуктом? Или большинство нововведений внутренние идеи и запросы пользователей?
И как дела с resharper? Есть информация что они что-то заимствуют у вас?
Andrey2008 Автор
Не знаю. Мы не отслеживаем это. Просто иногда случайно замечали подобное в C++ компиляторах, аналогично тому, как это было в описанном сейчас случае.
SemenPV
Кстати, искал на вашем сайте сравнения с конкурентами и не смог найти, было бы неплоо иметь что-то типа comparison chart и время от времени обновлять. Позволило бы держать руку на пульсе и сделало бы муки выбора для конечного пользователя немного меньше. Вместо галочек можно циферки ставить и т.п.
Andrey2008 Автор
Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода.
NR_electronics
Ждём с нетерпением появление полной поддержки всех трех стандартов MISRA C.
GGribkov
Если не секрет — с чем связана ваша заинтересованность в старых изданиях MISRA C? Ведь более современные версии стандарта содержат как новые правила, так и переосмысленные и доработанные старые. Ситуация здесь примерно такая же, как у разных изданий технической литературы — читать стоит самое последнее, ведь так?
P. S. Мы сейчас усиленно занимаемся поддержкой MISRA C:2012 и MISRA C++:2008.
На момент написания комментария в PVS-Studio есть 50 готовых MISRA-диагностик и еще около 20 на подходе (одна диагностика анализатора — это обычно несколько правил MISRA). И хотя наш анализатор уже можно использовать для проверки соответствия стандарту MISRA, мы продолжаем стремиться к полному покрытию всех правил. Поэтому ваше ожидание не проходит зря :)