Популяризируя статический анализатор кода PVS-Studio, мы обычно пишем статьи для программистов. Однако, на некоторые вещи программисты смотрят одностороннее. Именно поэтому и существуют менеджеры программных проектов, которые могут управлять процессом развития проекта направлять его в нужное русло. Я решил написать несколько статей, целевой аудиторией которых являются менеджеры программных проектов. Эти статьи помогут им лучше ориентироваться в вопросах использования методологии статического анализа кода. Сейчас мы рассмотрим ложный постулат: «ошибки кодирования несущественны».
Недавно я написал статью "Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам". Вполне закономерно к ней начали оставлять комментарии о том, что нет пользы от инструмента поиска простых ошибок. Приведу один из таких комментариев:
Причина простая: основные баги — в алгоритмах. В работе аналитиков, математиков, постановщиков, алгоритмистов. А багов при кодировании — не так много.
В общем, ничего нового. Опять мы встречаемся с мифом, что профессиональные разработчики не допускают простых ошибок. А если и допускают, то это не страшно: такие ошибки легко найти и, как правило, они не критичные.
Обсуждать утверждение, что профессионалы не допускают ляпов, я смысла не вижу. Эта тема уже много раз была разобрана мною в статьях. В конце концов, если всё так просто, почему все эти профессионалы наделали так много ошибок в известных проектах. На данный момент, нами найдено уже более 11000 ошибок в открытых проектах, хотя мы никогда не стремились выявить как можно больше ошибок. Это просто побочный продукт написания статей.
Сейчас мне интереснее обсудить вот какую тему: многие программисты считают, что по-настоящему серьезные ошибки можно допустить только при реализации алгоритмов. Вот здесь я хочу предостеречь менеджеров — это не так. Любая ошибка может быть критичной. Я не отрицаю, что ошибки в алгоритмах крайне важны, однако, не следует недооценивать важность опечаток и обыкновенных ляпов.
Некоторые программисты заявляют: раз анализатор не умеет искать ошибки в сложных алгоритмах, то он не нужен. Да, сложные алгоритмические ошибки анализатор искать не умеет, для этого нужен искусственный интеллект, который пока не создан. Тем не менее, искать обыкновенные ошибки в коде столь же важно и нужно, как и алгоритмические ошибки.
Чтобы не быть голословным, предлагаю вам 3 примера.
Для начала можно вспомнить критическую уязвимость в iOS, появившуюся из-за двойного goto.
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;Подробности изложены в статье Apple's SSL/TLS bug. Не важно появилась эта ошибка из-за опечатки или неудачного merge. Явно, это «механическая» ошибка, не имеющая отношения к математике или алгоритмам. При этом, подобная ошибка обнаруживается анализатором PVS-Studio.
Теперь вспомним уязвимость в MySQL: Security vulnerability in MySQL/MariaDB sql/password.c.
char foo(...) {
return memcmp(...);
}Ошибка возникает из-за неявного приведения типа (int -> char), при котором отбрасываются значения старших битов. Это вновь ошибка, которая не имеет отношения к сложным алгоритмам и прекрасно выявляется анализатором PVS-Studio. Не смотря на свою простоту, ошибка приводит к тому, что на некоторых платформах в 1 случае из 256 процедура сравнения хэша с ожидаемым значением всегда возвращает значение 'true', независимо от хэша.
Третий пример. Я участвовал в разработке пакета численного моделирования газодинамических процессов. Масса математики, алгоритмов и т.д. И, конечно, были связанные с этой математикой ошибки и проблемы. Однако, мне намного больше запомнились проблемы, возникающие из-за переноса кода на 64-битные системы. Кстати, именно тогда и зародилась идея создать анализатор Viva64, который потом развился в PVS-Studio (история: как 10 лет назад начинался проект PVS-Studio).
Одна из ошибок была связана с неправильным позиционированием в файле с помощью функции _fseeki64. Пакет моделирования, став 64-битным, смог обрабатывать больший объем данных и, как результат, записывать данные большего объема на диск. Вот только потом, не мог их правильно прочитать. Причем, нельзя сказать, что код был написан как-то уж очень плохо. Приблизительно там было так:
unsigned long W, H, D, DensityPos;
....
unsigned long offset = W * H * D * DensityPos;
res = _fseeki64(f, offset * sizeof(float), SEEK_SET);Возникает переполнение при перемножении переменных. В защиту программиста можно сказать, что, когда он писал этот код, сложно предположить, что в Win64 (ILP32LL) размер типа long останется 32-битным. Эту ошибку искали очень долго. Когда приводится вот такой псевдокод, кажется всё простым и понятным. На практике же, очень сложно было понять, почему при превышении определенного порога объёма обрабатываемых данных, начинаются странные ошибки. Неделю отладки легко можно было бы заменить проверкой кода с помощью PVS-Studio, который в два счёта нашел бы описанный баг. Алгоритмы и математика при переходе на 64-битную систему как раз не повлекли за собой никаких сложностей.
Как видите, простые ошибки могут приводить к серьезным последствиям. Лучше находить их как можно больше с помощью статического анализатора, а не проводя часы и дни в отладчиках. И уж тем более, лучше найти ошибку самим. Худший вариант: выясняется, что ваше приложение содержит уязвимость, но оно уже инсталлировано на десятках тысяч компьютеров.
Да и просто полезно найти как можно больше простых ошибок с помощью инструментов, чтобы посвятить себя поиску дефектов в алгоритмах и созданию новой функциональности.
Кстати, предлагаю менеджерам, читающим эту статью, воспользоваться нашими услугами по проверке их проектов. Предлагаем заключить маленький контракт, в рамках которого мы исследуем проект и исправим все ошибки, которые сможем найти. Во-первых, это в любом случае будет полезно, а во-вторых, если результат вам понравится, это откроет путь для дальнейшего сотрудничества. В случае необходимости мы готовы подписать NDA. Предлагаю обсудить детали по почте.
Дополнительные ссылки:
- Страница PVS-Studio.
- Мифы о статическом анализе. Миф первый – статический анализатор это продукт разового применения.
- Мифы о статическом анализе. Миф второй – профессиональные разработчики не допускают глупых ошибок.
- Мифы о статическом анализе. Миф третий – динамический анализ лучше чем статический.
- Мифы о статическом анализе. Миф четвёртый – программисты хотят добавлять свои правила в статический анализатор.
- Мифы о статическом анализе. Миф пятый – можно составить маленькую программу, чтобы оценить инструмент.
- В дополнении к пятому мифу: Почему я не люблю синтетические тесты.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. If the coding bug is banal, it doesn't meant it's not crucial
Комментарии (82)
duger
19.04.2017 13:59+3До сих пор помню одну из самух труднонаходимых моих ошибок:
if (...); { // do smth }
SirEdvin
19.04.2017 14:15+1Недавно я написал статью "Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам". Вполне закономерно к ней начали оставлять комментарии о том, что нет пользы от инструмента поиска простых ошибок. Приведу один из таких комментариев:
Не совсем понятно, к чему популизировать миф, как будто все программисты против статического анализа или ненавидят его?
Человек написал, что он один раз попробовал один из них, убил впустую три дня. Окей, из-за этого он убедился, что они ему не нужны. Ну может быть.
А причем тут остальные программисты и "закономерно"?
SirEdvin
19.04.2017 14:20+1Причем, как уже вам написали, в 99% случаев причиной для того, что бы не использовать инструменты статического анализа является менеджер — "нет денег", "это все глупость", "вот выкатим релиз/второй релиз/… и займемся анализом" и так далее.
Andrey2008
19.04.2017 14:20Закономерно, что обязательно есть кто-то, кто скажет «не нужно».
SirEdvin
19.04.2017 14:39+1Практически на каждую технологию есть кто-то, кто скажет "не нужно", потому что у него был другой случай, когда статический анализ не помог и не мог помочь.
Аналогичная ситуация с юнит-тестами, ООП, паттернами и розовыми поняшками. Мне кажется странным делать из этого причину для отдельной статьи.
К тому же, учитывая что, что большинство людей в целом вас поддержало.
Jef239
19.04.2017 21:54-1Точнее — не выгодно. Критерий выгоды вам уже писали, вроде он был 1 день труда разработчика в месяц. Поскольку цена на PVS-studio секретна, только вы сами можете назвать количество разработчиков, при которых цена начнет оправдываться.
edogs
19.04.2017 19:17+1Не совсем понятно, к чему популизировать миф, как будто все программисты против статического анализа или ненавидят его?
Так маркетинг. Вы посмотрите контекст последних статей.
«Наш анализатор необходим каждому, а программисты возражают против него просто из вредности, боязни и т.д… Купи анализатор, докажи что ты круче программиста, поставь засранца на место»:)SirEdvin
19.04.2017 20:23Не уверен, что это работает.
Вроде как большинство менеджеров, которым такое нужно и так кажется, что они круче программистов.
Andrey2008
20.04.2017 12:38Купи анализатор, докажи что ты круче программиста, поставь засранца на место»
Кстати, в этом что-то есть. Я не призываю так поступать, однако иногда умелое использование такой методики пожалуй может дать воспитательный эффект. :)
webkumo
20.04.2017 18:15+1Проблема в том, что:
- индюки и без того в этом уверены,
- большая часть из тех, кто всё-же захочет опустить (к счастью таких не очень много) будет пытаться добиться инфы "а как опустить", потому что сам с инструментом не справится
- остальные деляется на четыре подкатегории
а программисты им уже устали объяснять, как полезен стат. анализ
б у проекта нет средств
в они уже купили инструмент стат.анализа
г программисты продавили использования опен-сорсных решений стат. анализа (это больше касается java, возможно в каких-то ещё экосистемах есть качественные оперсорсные решения стат.анализа).
Т.е. вы изначально не с той категорией работаете. Вам ведь нужны категории 3а и 3б, возможно попытаться зацепить 3в и 3г. А для них нужен другой материал — в чём будет заключаться выгода на их языке. А это экономический язык… чего я у вас ни разу не видел.
Am0ralist
19.04.2017 22:39+1как будто все программисты против
Странно, написано вроде понятно, но вы при этом умудрились прочитать исключительно то, что захотели.
Давайте начнем с самого простого с точки зрения логики. Покажите в посте кусок текста, из которого возникают ваши «все программисты»?SirEdvin
20.04.2017 02:27+1Например
Сейчас мне интереснее обсудить вот какую тему: многие программисты считают, что по-настоящему серьезные ошибки можно допустить только при реализации алгоритмов
В аналогичном ключе была написана и оригинальная статья.
Из-за нее складывается впечетление, что большинство профессиональных и опытных программистов считают, что статический анализатор не нужен, но это далеко не так.
В комментариях большинство в целом согласились со статьей, но на основе комментариев одного человека, была написана еще одна статья, которая опять получилась в духе "программисты не понимаю, что статический анализ нужен".
Где все эти программисты?
Возможно, я предвзят, но у меня сложилось впечетление, что это определенно попытка популяризации какого-то странного мифа про программистов.
Andrey2008
20.04.2017 12:41Где все эти программисты? Возможно, я предвзят, но у меня сложилось впечатление, что это определенно попытка популяризации какого-то странного мифа про программистов.
К сожалению, их много. Если у вас есть пара недель свободного времени предлагаю прочитать все комментарии, ко всем нашим статьям в блоге. Вы увидите, что я пишу это от того, что «наболело».SirEdvin
21.04.2017 13:56Я просмотрел нестолько статей и, честно говоря, не особо увидел, кучи людей, которые бы в каждой статье писали, что "статические анализаторы не нужны".
С тем, что они не нужны в их случае, потому что у них и кода мало, и проект не такой прибыльный и прочее сложно не согласится.
Или я не прав, и находятся люди, которые утверждают, что статический анализ бесполезен для любых проектов?)
Am0ralist
21.04.2017 08:08+1И вам тоже, сравните
как будто все программисты против
многие программисты
Многие != всем. Многие != большинству.
Многие — это просто какое-то заметное количество людей. Больше одного и однозначно меньше 100%.
Из-за нее складывается впечетление, что большинство профессиональных
Поэтому, когда кажется — крестится стоит.
на основе комментариев одного человека
Одного? В прошлой статье было минимум два хейтера, когда я перестал читать. Под другими статьями тоже возникали подобные. С учетом, что в основном тут обсуждение под каждой статьей вообще небольшим количеством людей идет даже когда комментов много, то да, из десятка-полутора 2 хейтерищих — это заметное количество, особенно учитывая количество оставляемых ими комментариев.
Возможно я предвзят, но покажите мне хоть одну достаточно сложную программу без тонны багов. А потом прошу уточнить, сколько лет ее вылизывали. «Программисты» сами своими подходом к написанию ПО уже создали определенный миф у людей, потому как процент говнокодеров, мнящих себя профессионалами, больно заметен окружающим. Как и людей, любящих интерполировать исключительно свой опыт на всю отрасль (для примера см. комментарии хейтера уже под этим постом).SirEdvin
21.04.2017 13:27Как и людей, любящих интерполировать исключительно свой опыт на всю отрасль
Вы делаете абсолютно так же, когда утверждаете, что "статический анализ в каждый проект". Большинство проектов — это мелкие или средней сложности сайты, для которых внедрение с статического анализа и его поддержка банально не окупится.
Многие — это должно быть достаточно весомое количество. Я понимаю, когда говорят, что многие программисты выступают против TTD, я вижу, их мнение доходит до Хабра, например.
А кто те многие, которые выступают против статического анализа?
Загуглив "статический анализ не работает" я не могу найти статьи, которые бы говорили против него, найти такое же для TDD не составит труда.
Так кто эти "многие"?
Andrey2008
21.04.2017 14:31А кто те многие, которые выступают против статического анализа?
Я видел их в комментария, в почте. Но я никогда не собирал ссылки на такие дискуссии, поэтому не могу сейчас достать список «100 примеров». В общем с пруфами затруднение и даже как поискать не знаю. С ходу только вспомнилась заметка "Народ против PVS-Studio: дубль первый" с выводом в конце: не следует полагаться на анализаторы, скорее нужно просто повысить свой уровень профессионализма. Формально вывод правильный, но при разборе статьи выясняется, что автор просто не разобрался в вопросе.SirEdvin
21.04.2017 14:48Возможно, я не прав, но учитывая, что автор проводил сравнение инструментов синтаксического анализа, то вряд ли он выступал против использования таких инструментов.
На мой взгляд, выступать против можно так: Исследование, в котором говорится, что TDD не работает
А так, как никто не ожидает от статического анализа серебрянной пули и того, что он решит все проблемы, то и выступать против него никто не собирается. Ну, или мне так кажется.
Am0ralist
21.04.2017 16:02Вы делаете абсолютно так же, когда утверждаете, что «статический анализ в каждый проект».
А можете уточнить, где? Где это делаю я? Именно я, м?
zenkz
19.04.2017 17:15+1Статический анализатор — вещь хорошая. Пользовался продуктом от HP.
К сожалению часты ложные срабатывания.
Проблема использования статических анализаторов одна — деньги:
Менеджеры не дают денег, а компании разрабатывающие такие продукты хотят очень много денег (от части обоснованно, т.к. алгоритмы довольно сложные, а задача нетривиальная).
Вообще статический анализ должен стать частью IDE — может быть когда-нибудь увижу его в Visual Studio.
По поводу приведённых примеров — это скорее всего результат работы неопытных разработчиков, т.к. большинство опытных знают, что if лучше не использовать без { }. А все остальные примеры актуальны только для C++, т.к. в Java или C# либо компилятор не позволит такое сделать, либо просто нет необходимости манипуляции на уровне байтов.
SvyatoslavMC
19.04.2017 18:04+2Вообще статический анализ должен стать частью IDE — может быть когда-нибудь увижу его в Visual Studio.
PVS-Studio есть для Visual Studio (скрины), так же там есть стандартные простые статические анализаторы для C++ и C#, или что вы имели ввиду?zenkz
19.04.2017 20:11Я про то, что было бы неплохо иметь статический анализатор как часть Visual Studio, а не как плагин или стороннее решение. (Пусть даже и менее функциональный чем ваше решение или вариант от HP).
Andrey2008
19.04.2017 22:33+2Так он уже есть как часть Visual Studio. Т.е. в Visual Studio уже есть встроенный статический анализтор. Только пользоватся на практике им нельзя. Мало толковых предупреждений и очень много не по делу.
- Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
- Как мы сравнивали анализаторы кода CppCat, Cppcheck, PVS-Studio, Visual Studio
Jef239
19.04.2017 22:00А статический анализ и так есть в любом компиляторе. Точнее его самая важная часть — 95% наиболее полезных диагностик. Любой статнализатор — это гонка за оставшимися 3-5 процентами.
Andrey2008
20.04.2017 12:46+1Вы сильно преувеличиваете. К сожалению, подтвердить свои слова я не могу. Для этого нужен проект, который разрабатывался с ключём -w0 (т.е. без предупреждений). Тогда бы можно было запустить компилятор и анализатор и сравнить результаты. Я предполагаю, что анализатор найдет как минимум в 2-3 раза больше, чем компилятор. Однако, тут никаких пруфов нет: только Ваше мнение против моего.
Jef239
20.04.2017 13:31-3Ну тогда обратите внимание, что 100% приведенных вами в данной статье примеров — обнаруживаются компиляторами.
Понимаю, вам кажется, что это случайность. Ну а мне — что закономерность. Проявление правила про 20% людей, выпивающих 80% пива. Иными словами, разработчики компилятора включают в него лишь самые полезные варианты статанализа.
Подумайте о том, что у сырого кода плотность ошибок может достигать 100 на 1000 строк. А когда вы тестируете открытые проекты — плотность сильно меньше. И достигается это как раз компилятором.
Сделайте тест на своем проекте. Напишите тысячу строк кода без компиляции. И посмотрите число ошибок, которые даст компилятор при -Wall -Wextra и PVS-Studio.
Andrey2008
20.04.2017 15:07+1Это исключительно Ваше мнение, основанное на желании убедить себя и других, что статический анализ не нужен. У меня другое мнение, основанное на опыте и желании продать анализатор :). Спор бесперспективен.
Oxoron
19.04.2017 21:01Причина простая: основные баги — в алгоритмах. В работе аналитиков, математиков, постановщиков, алгоритмистов. А багов при кодировании — не так много.
Вы уводите дискуссию в другой русло. Jef239 весь исходный пост пытался добиться ответа на вопрос: при каких условиях внедрение PVS-Studio окупится? Единственная внятная метрика, которую вы указали: размер проекта, минимум (условный) 250,000 Lines of Code.
Судя по текущей статье, добавляется еще одна метрика: проект должен быть уровня iOS или MySQL (подозреваю, в такого роде проектах уже есть 250k LoC).
Вы можете предложить еще какие-то параметры оценки окупаемости PVS-Studio?
AndreyMust19
19.04.2017 21:40+1А в C/C++ библиотеках разве нет таких констант, которые содержат размер типов данных на текущей платформе? Это вместо того, чтобы гадать — будет или не будет long 32-битный.
Andrey2008
19.04.2017 21:43Всё есть. Но перенести программу на 64-битную систему намного сложнее, чем кажется:
Jef239
19.04.2017 22:24Вы несколько переврали то, о чем я писал. Основные вопросы:
- Когда статический анализ начинает оправдывать время, затраченное на разбор его предупреждений?
- Когда PBS-Studio начинает оправдывать свою цену?
- Когда покупка PVS-Studio становится выгоднее иных мер?
- Когда багфиксинг становится выгоднее развития проекта? То есть появляется смысл сокращать технический долг, а не накапливать его?
- Когда поиск потенциальных ошибок важнее исправления реально проявляющихся ошибок?
На первый вопрос есть ответ про 250КLoc.
На второй — есть гипотеза, что это происходит когда ФОП за 1 день в месяц всех девелоперов (12 дней в год) становится больше цены PVS-Studio. Видимо это означает от пары сотен разработчиков.
На третий скорее всего ответ — когда матстимулирование уже не помогает. То есть зарплаты разработчиков настолько превышают среднюю оплату, что премии уже не дают отдачи. Впрочем, могу быть неправ. Кроме того, есть условно-бесплатные техники вроде TDD.
На четвертый — скорее всего тогда, когда маркетологи с трудом придумывают, а что бы ещё включить в новую версию. Ибо вся основная функциональность уже есть. а то, что просят — нужно лишь единицам пользователей.
На пятый — видимо речь о специальных областях с большими рисками. АСУТП, банковские приложения, космос и так далее — везде, где можно потерять миллионы долларов. Разумный критерий — если цена скрытой ошибки больше, чем в сто раз превышает стоимость статанализатора — его есть смысл применять.
А на то, что вы написали — отвечу чуть позже.Andrey2008
20.04.2017 14:59+1Такого расчета нет и не будет в силу его сложности. Слишком много факторов и субъективных мнений которые невозможно учесть. Сейчас я приведу аналогию.
Перед вами стоит задача купить 10 компьютеров для нового отдела программистов. Вы не будете делать никакой расчет по оценки окупаемости. Вот как оценить нужно купить мышку за 300 или 400 рублей? Первая дешевле, но вторая надежнее. Как выбрать? Проводить опрос у программистов, читать обзоры? А монитор — 22 или 25 дюймов? Что лучше? Первый дешевле, а второй показывает больше кода и программисты возможно будут работать быстрее. Как посчитать окупаемость для монитора? А стоит экономить на памяти или нет? А наушники нужны для большего комфорта или обойдутся без них?
В итоге вы будете действовать на глазок. Вы просто понимаете, нужен компьютер вот с такой конфигурацией или нет. А от меня хотят услышать такой же сложный расчёт для анализатора. Ведь в нем как и с компьютером много субъективного. Кто может посчитать на сколько процентов увеличивают эффективность работы мониторы разного размера?
Так как же тогда выбирают компьютеры для команды программистов? По ощущению. Вот тоже самое получается и со статическим анализом. Он или нужен или нет. Или чувствуется потребность или нет. Ибо что с компьютерами, что со статическим анализатором траты на зарплаты не соизмеримо больше.Jef239
20.04.2017 20:49С компьютерами как раз все просто. На кривой цена-параметр у каждого компонента есть изгиб. До этого изгиба небольшое изменение цены сильно увеличивает параметр, после — для увеличения параметра нужно сильное увеличение цены. Вот вблизи изгиба и выгодней всего покупать.
А от вас я жду не расчета, а оценки. Если вы не имеете такой оценки — значит вы не имеете образа покупателя и не понимаете, кто ваш клиент, а кто нет.
Отсюда — и те заявления, что меня раздражают своей всеобщностью.
А заказчику перед покупкой все равно приходится такой анализ сделать. Если покупка компа в любом случае выгодна и речь идет о процентах, то станализатор вполне может не окупиться. Ну например в моем случае (до 50КLoc в основном проекте) — килобаксы за PVS-studio не окупятся.Am0ralist
21.04.2017 08:11+2На кривой цена-параметр у каждого компонента есть изгиб
Пруф будет? С кривыми по каждому компоненту.
Или вы только что доказали предыдущее утверждение, что подбор конфиги идет на глазок.
Jef239
19.04.2017 23:40Мне не нравится, что вы передергиваете.
Опять мы встречаемся с мифом, что профессиональные разработчики не допускают простых ошибок.
Допускают. Ещё как допускают — компилятор каждый день мне говорит об этом. Но:
- Ошибки бывают как в кодировании, так и в алгоритмах, матметодах, менеджменте (я про мисфичи)
- Большую часть ошибок кодирования находит компилятор.
- Статанализатор находится лишь часть ошибок, оставшихся после компияции.
Пример из РД 50-25645.325-89:
Запятую вместо точки в коде мне найдет компилятор. А кто найдет + вместо — (реальная ошибка в ИКД ГЛОНАС)? А если 1 вместо 7?
А вот любимый пример мисфичи. Несмотря на максимально жесткое тестирование авионики просто забыли включить функциональность в результирующий проект. Примерно аналогичная ошибка похоронила 3 спутника ГЛОНАСС. Там изменили размеры бака, но ни расчетчики, ни QA этого не поняли.
Ну а вот и ваша статья о менеджерских ошибках в развитии проекта PVS-Studio. Ошибки дорогостоящие. но статический анализ их никак не ловит.
В итоге получается примерно так. 40% ошибок — это кодирование. Из них 70% ошибок (28% всех ошибок) находит компилятор. Из оставшихся 12% ошибок статанализ находит 3-5%. То есть — 0.4-0.6% общего числа ошибок находятся статаналиом.
Понятно, что цифры — условные, жду от вас вашей собственной оценки.
Ну и о ваших примерах. goto fail вне if — ну так dead code находится компилятором. Это как раз та часть статанализа, которую компиляторы обычно умеют. Неявное приведение типа с обрезанием значимой части — опять диагностируется компиляторами. Третий пример — целочисленное переполнение. И опять — зачастую компиляторы это умеют, правда не статически, а динамически.
В итоге получается, что рекламируя платный продукт вы на самом деле рекламируете возможности компиляторов. Причем зачастую — бесплатных компиляторов.
Ну а о том, что компилировать надо с -Wall -Wextra — никто не спорит.Andrey2008
20.04.2017 15:21+2Не вижу смысла вдаваться в споры. Вы столь критически настроены, что всё равно не хотите воспринимать, что компиляторы весьма слабо анализируют код, выдавая при этом слишком много ложных срабатываний. И именно поэтому всякими -Wall -Wextra мало кто пользуется. Неудобно!
Если бы это было не так, не было этой базы с 11000 ошибками.
И именно поэтому статические анализаторы такие как PVS-Studio или Coverity были, есть и будут. Они всегда идут на шаг или два впереди компиляторов в плане диагностик.
Увлекаясь критикой стат. анализторов, Вы начинаете приписывать компиляторам магические возможности, которых нет. Например, так дело обстоит с целочисленным переполнением. Эта и подобные ошибки положили начало созданию Viva64, который со временем превратился в PVS-Studio. И искать подобные ошибки компиляторы не умели, не умеют и не собираются учиться. Что-бы не быть голословным, буквально на днях у нас появился новый клиент, купивший лицензию на PVS-Studio ради 64-битных диагностик. Именно ради них! Видимо пришло делать 64-битнео приложение, а оно не работает… :)Jef239
21.04.2017 01:39+1Про 64биты — вы правы. Там действительно более чем хватает проблем с переходом. Или собственный колхоз на регулярных выражениях — или покупка готового.
Вы начинаете приписывать компиляторам магические возможности, которых нет. Например, так дело обстоит с целочисленным переполнением
-fsanitize=signed-integer-overflow
This option enables signed integer overflow checking. We check that the result of +, *, and both unary and binary - does not overflow in the signed arithmetics.
Это такая особая рантаймовая магия. Но знание — сила, а незнание — силища богатырская. Знали бы про неё — не было бы PVS-Studio. Но ничего нового в ней нет — эта технология применяется в компиляторах года с 1965ого.Расставляются инструкции условного перехода по установленному carry-биту, остальное делает рантайм.
Они всегда идут на шаг или два впереди компиляторов в плане диагностик.
Согласен. Личный самолет — круче велосипеда. Вот только покупают его единицы.
компиляторы весьма слабо анализируют код, выдавая при этом слишком много ложных срабатываний. И именно поэтому всякими -Wall -Wextra мало кто пользуется. Неудобно!
Не так уж и много, 10% хинтов и 50% варнингов — это реальные ошибки. А вот у cppcheck — 99% — не по делу.
А вот clang static analyzer хочется попробовать. Если скажите, где найди виндовую сборку — буду рад. СУдя по вашей же статье — он похож на лучший из бесплатный.Andrey2008
21.04.2017 08:06-fsanitize=signed-integer-overflow
Ну-ну… Попробуйте искать так ошибки в большом проекте. Да и вообще, никто не обещал, что переполнение будет целочисленным. Я же написал:
unsigned long W, H, D, DensityPos; .... unsigned long offset = W * H * D * DensityPos; res = _fseeki64(f, offset * sizeof(float), SEEK_SET);Jef239
21.04.2017 15:29И что тут не целочисленное? Может вы имели ввиду знаковое?
Andrey2008
21.04.2017 16:38-1Да. Опечатался:
Да и вообще, никто не обещал, что переполнение будет знаковым.Jef239
22.04.2017 02:40-1Тогда у вас ошибка была ещё до перехода к 64битности. В fseek второй параметр long и компилятор должен был предупредить, что вы ему подсовываете unsigned long.
Так что компиляторная магия — не так уж и плоха.
Jef239
20.04.2017 02:55Предлагаем заключить маленький контракт, в рамках которого мы исследуем проект и исправим все ошибки, которые сможем найти. Во-первых, это в любом случае будет полезно, а во-вторых, если результат вам понравится, это откроет путь для дальнейшего сотрудничества. В случае необходимости мы готовы подписать NDA. Предлагаю обсудить детали по почте.
А вот это стоит отдельной статьи. Ибо мнения о том, что статанализ есть смысл предоставлять как сервис — я читаю уже 3-4 года в комментариях к вашим статьям.
Вопрос, как обычно в цене. Сколько будет стоит получение полного лога без исправления ошибок? Сколько будет стоить ручная фильтрация ложных предупреждений? Про исправление не спрашиваю — исправление, сделанное без понимания проекта все равно полетит в мусорную корзину.
P.S. При разумных ценах — прогнозирую бешеный успех.dimm_ddr
20.04.2017 10:09+2Вряд ли взлетит. Все-таки стат анализ нужен не разово, а постоянно. Это как с тестами: написать их один раз полезно, но обычно слишком затратно, пользу они начинают приносить позже, когда показывают не сломалось ли чего после новых изменений. Вряд ли много компаний будут готовы платить за разовое применение анализатора столько, сколько при такой модели заработка будут просить разработчики этого анализатора. Хотя без конкретных цифр сложно сказать наверняка, ситуации разные бывают.
Jef239
20.04.2017 11:07-3Польза разовой проверки для клиента понятная — это ачивка «проверено, мин нет». С другой стороны — это аутсоринг. А аутсоринг обычно выгоден обоим сторонам. Но для этого нужна автоматизация и в оплате договоров и в проверке. То есть — SaaS. Собственно так работает один из тяжелых анализаторов (вроде coverity).
Польза для производителя тоже понятна — это подкормка рыбы перед подсчечкой. Во время SaaS выясняются финансовые возможности клиента и особенности его софта.
А вот какую модель ценообразования они выберут… Письмо я написал, в ответ «да и нет не говорите, черное и белое не называйте». О цене — молчат как партизаны на допросе. Будем считать это вежливым отказом в обслуживании.
Для SaaS ценообразование понятное — в основе экономия времени клиента на установку бесплатной версии. То есть несколько дней ФОП девелопера. Дальше это все множится на жадность производителя (с учетом выгоды от обнаружения ошибок).
Интересный финт ушами будет, если цена будет зависеть от количества обнаруженных ошибок по сравнению с прогнозом. Программеры все оптимисты, так что на этом можно заработать.
Andrey2008
20.04.2017 15:24Вряд ли взлетит. Все-таки стат анализ нужен не разово, а постоянно.
Мы думаем, такие проверки могут быть хорошим способом познакомиться и продемонстрировать возможности PVS-Studio. А даже если дальнейшее сотрудничество не сложится, в программе станет меньше багов, что тоже хорошо.vesper-bot
20.04.2017 15:39+1ИМХО нужно популяризировать статический анализ, в том числе и как SaaS, и сделать его доступным, скажем, инди-студиям за пару тыщщ деревянных за запуск. Они будут пользоваться им раз в полгода, найдя все опечатки, потом подсядут, а то и лучше кодить начнут — особенно если из-за какого-нибудь интересного бага, который не вылавливается силами программистов по какой-либо причине, но ловится стат.анализатором, придется его запустить, после чего какой-нибудь git blame покажет, кто сделал этот баг, и с него полетят денежки. Денежный стимул — самый серьезный в современном мире "волшебный пендаль". Если вы сможете (вопрос, к сожалению, сложный — для проверки проекта потребуется реально развернуть весь проект со всеми сторонними библиотеками, если я правильно понимаю механизм работы PVS-Studio) предоставить статический анализ как услугу, мне кажется, она будет востребована довольно большим числом людей, чтобы появилась достаточная для окупаемости конверсия.
SirEdvin
21.04.2017 14:52Мне кажется, идеальными были бы лицензии по количество сотрудникам или строкам кода)
olen
20.04.2017 16:23Нигде не нашел информации о типе поддерживаемых проектов. Работает ли PVS с проектами ASP.NET MVC Core (вместо файла проекта project.json)?
На днях ради интереса скачал и запустил ваш плагин на одном своем проекте, но на любые попытки анализа PVS ругается, что это не C++ или C# проект. Такое впечатление, что он не видит стандартного файла проекта и больше ничего делать не хочет.
P.S. В поддержку писать не стал, т.к. интерес чисто академический.
Paull
20.04.2017 16:47+1Плагин PVS-Studio поддерживает проекты форматов vcxproj\csproj. Касательно ASP.NET, Microsoft отказалась от поддержки json\xproj в последней версии ASP.NET (подробно про это можно почитать здесь). На момент выхода Roslyn 1.0, xproj ещё не поддерживался в Roslyn, а когда мы обновили C# анализатор до Roslyn 2.0, об отказе от поддержки xproj уже стало известно, поэтому мы решили не добавлять поддержки для этого типа проектов. ASP.NET проекты на csproj должны проверяться.
olen
20.04.2017 16:57+2Да, верно у меня проект .xproj / project.json. Статью по вашей ссылке читал еще раньше. Странно, но VS 2015 Update 3 именно такие проекты и создает (если выбрать ASP.NET Core).
Но все равно, спасибо что подтвердили мою догадку.Paull
20.04.2017 17:07Странно, но VS 2015 Update 3 именно такие проекты и создает (если выбрать ASP.NET Core).
Начиная с VS2017 такой тип проектов использует уже csproj. К сожалению, пользователи ASP.NET Core на VS2015 у нас пока-что выпали из поддержки.
Andrey2008
20.04.2017 16:58Решил немного развить мысль про аудит кода и других услуг: Команда PVS-Studio: аудит кода и другие услуги.
evkin
20.04.2017 23:33А с помощью чего вы анализируете/проверяете JAVA проекты? (Как разовый, так и регулярный аудит вашего кода (C, C++, C#, Java).)
Jef239
21.04.2017 01:57-1Цен все равно нет и так просто их не получить.
Более того, в эксперименте не удалось даже понять масштаб цен.
Bonart
21.04.2017 19:28-8PVS-Studio соткан из противоречий.
Рекламирует себя как B2B но почему-то в виде массового спама статьями на хабре.
Уступает Coverity по глубине анализа, а решарперу по всем прочим пользовательским характеристикам сразу.
Как результат — ниша очень дорогого дополнения к имеющемуся инструментарию, чья единственная ценность в правилах, которые не покрывает решарпер.
Прибыльность такого бизнеса столь же загадочна как и цена продукта.Am0ralist
21.04.2017 21:01а что, решарпер могет в C/C++?
Bonart
22.04.2017 01:21+1Внезапно, да:
http://jetbrains.ru/products/resharper-c/Am0ralist
22.04.2017 09:25Спасибо, два года назад пропустил новость, а в мозгах отложились лишь старые возможности.
Andrey2008
22.04.2017 15:34решарпер
Не стоит смешивать статические анализаторы кода и productivity tools. Статический анализ это подробная документация по всем диагностикам, поддержка и консультирование, это интеграция с IncrediBuild, это Standalone, это инструменты интеграции в большой проект (например, база разметки сообщений), отслеживание запусков компилятора (CLMonitoring), рассылка писем и т.д.Bonart
22.04.2017 21:20-5Не стоит дезинформировать читателей:
Статический анализ кода это процесс выявления ошибок и недочетов в исходном коде программ. Статический анализ можно рассматривать как автоматизированный процесс обзора кода.
Я надеюсь, вы знаете, откуда эта конкретная цитата. Этому определению решарпер полностью удовлетворяет.
Википедия:
Стати?ческий ана?лиз ко?да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ
И этому определению решарпер полностью удовлетворяет.
Сайт JetBrains:
Статический анализ качества кода и автоматическое исправление обнаруженных проблем
Для всех поддерживаемых языков ReSharper распознает ошибки компиляции, времени выполнения и логические ошибки, а также избыточные и неоптимальные конструкции, и подсвечивает обнаруженные проблемы прямо в редакторе. Более тысячи инспекций, которые ReSharper использует для поиска проблем в коде, позволят мгновенно увидеть все потенциально опасные места в текущем файле или даже во всем решении Visual Studio. Для большинства из них ReSharper предложит один или более вариантов автоматического исправления.Даже если вы сами избегаете сравнения с решарпером любой ценой, потенциальные клиенты все равно будут это делать.
Причем никакие ваши плюшки не побьют решарперовскую обратную связь в реальном времени, если только ваше средство не будет обнаруживать дефекты, которые решарпер не находит.
Вы можете дать такие примеры?Andrey2008
22.04.2017 23:05+1Использование ReSharper не мешает находить нам ошибки в C# проектах.
Что касается C++ то, я заявляю, что PVS-Studio лучше многих анализаторов кода (ReSharper, Cppcheck, ...). Наступаем на пятки и в ближайшее время превзойдём по многим направлениям Coverity и Klocwork. Я знаю, что PVS-Studio крут и мы регулярно это показываем на практике. Если кто-то хочет опровергнуть, пусть попробует доказать обратное.Oxoron
23.04.2017 00:55-2Использование ReSharper не мешает находить нам ошибки в C# проектах.
Andrey2008 вы гарантируете, что использование PVS-Studio позволит забыть о диагностиках выдаваемых R#?Bonart
23.04.2017 03:19+3@Andrey2008 этого и не утверждал.
Со своей стороны могу точно сказать, что статическим анализом решарпера пренебрегать нельзя. Например, несколько классов с дефектами из статьи по ссылке он справедливо предлагает выкинуть как неиспользуемые.
Ну и результаты выдает в реальном времени прямо в студии
SvyatoslavMC
23.04.2017 11:30В соседней ветке Jef239 гарантирует, что если использовать компилятор, то можно забыть о статических анализаторах…
Но вы же понимаете, что у анализаторов такие же гарантии, как и у компаний, выдающих самые крутые сертификаты безопасности. От продуктов есть выгода и польза, но никто не требует невозможного.
И R# не статический анализатор, а большая большая надстройка с горой функционала, среди которого анализ кода далеко не основная задача, а совсем малая часть. И вообще Вы можете найти много негативных отзывов о производительности R# при разработке, и сами разработчики это знают, поэтому ограничены в возможностях. PVS-Studio же занимается только статическим анализом, что за тоже самое время позволяет получить совсем другое качество анализа.Bonart
23.04.2017 13:48-1И R# не статический анализатор
Да неужели?
Решарпер умеет много чего еще, но собственно статическим анализом (по определению с вашего же сайта!) занимается в первую очередь.
Почему вы отрицаете очевидное?
И вообще Вы можете найти много негативных отзывов о производительности R# при разработке, и сами разработчики это знают, поэтому ограничены в возможностях.
У решарпера имеются проблемы с производительностью на больших проектах в реальном времени. Насколько мне известно PVS Studio в таком режиме вообще не работает.
PVS-Studio же занимается только статическим анализом, что за тоже самое время позволяет получить совсем другое качество анализа.
Время на что именно сравнивалось и где?
SvyatoslavMC
23.04.2017 18:16И R# не статический анализатор
Да неужели?
Именно так, статический анализ одна из возможностей, как и у компилятора.
ReSharper (R#) — дополнение (плагин), разработанное компанией JetBrains для повышения продуктивности работы в Microsoft Visual Studio.
ReSharper повышает эффективность разработки в Microsoft Visual Studio и помогает автоматизировать большинство рутинных процедур.
А теперь представьте, если всё это выкинуть и заняться только глубоким статическим анализом, будет совсем другой эффект.Bonart
23.04.2017 23:52+1Именно так, статический анализ одна из возможностей, как и у компилятора.
С точностью до наоборот. Вы почему-то трактуете включение как исключение.
А между тем и компиляторы, и решарпер являются статическими анализаторами и более того, активно используются в этом качестве.
И без сравнения с ними никакому иному статическому анализатору (PVS Studio) не обойтись.
А теперь представьте, если всё это выкинуть и заняться только глубоким статическим анализом, будет совсем другой эффект.
Мне не нужно ничего представлять, мне нужен конкретный результат. Если вы заявляете что PVS Studio быстрее решарпера, то покажите где и насколько (этого я не видел). Если заявляете что анализирует глубже — покажите случаи, когда PVS Studio находит ошибки, которые не по зубам решарперу (это я сделал за вас).
Ответы "X (делающий статический анализ) не статический анализатор" для вашего продукта скорее вредны чем бесполезны.
Jef239
23.04.2017 18:42+1Я писал мягко говоря другое. Время, потраченное на -Wall -Wextra оправдывается. Сводя предупреждения компилятора к нулю мы выигрываем больше, то время, которое мы теряем. А вот время, потраченное, чтобы свести к нулю все предупреждения cppcheck не оправдывается.
PVS-studio скорее всего оправдает потраченное на разбор время, но не оправдает те килобаксы, за которые он продается.
А пиратить продукт российских коллег просто не хочется.
Bonart
23.04.2017 03:16+3Использование ReSharper не мешает находить нам ошибки в C# проектах.
Очень хорошая иллюстрация к вашим тезисам.
Я чисто для проформы скачал этот проект себе и проверил решарпером.
Результаты (сравнение про найденным дефектам из вашей статьи):
- Ошибку с безусловной рекурсией и переполнением стека решарпер успешно находит.
- Ошибку с TimeSpan.Seconds решарпер не нашел.
- Пропущенное значение в switch решапер нашел.
- Отсутствие использования значения чистой функции Except решарпер нашел.
Про отрицательное значение в методе Substring у вас ложное срабатывание во всех трех случаях, причем для понимания этого факта в первом случае достаточно посмотреть на строку выше от цитаты.
if (!identityEntry.StartsWith("/")) return null; var indexOfEquals = identityEntry.IndexOf("="); if (indexOfEquals < 0) return null; var key = identityEntry.Substring(1, indexOfEquals - 1);
После первой строки в IdentityString первый символ всегда слеш по построению и IndexOfEquals никогда не будет равен нулю.Остальные два случая полностью аналогичны.
- Для операции ?? решарпер точно так же определяет что первый аргумент не может оказаться null
- Всегда ложное значение условия в if решарпер пропустил.
- Возможность словить NRE в данном случае решарпер пропустил.
Итоги:
- Решарпер для статического анализа кода в Orchard или не используется вообще или это делается заведомо неправильно.
- PVS Studio находит реально опасные дефекты, которые не обнаруживает решарпер.
- Польза от использования конкретно PVS Studio есть, но авторы инструмента допускают наличие дезинформации (уверен, что непреднамеренной) в своих материалах.
- Решарпер может и должен использоваться в том числе как статический анализатор кода.
lany
26.04.2017 17:02+5Пропустил статью :-) Мне регулярным евангелизмом статического анализа лень заниматься, так что дарю вам ещё довод, раз уж вы занимаетесь. Ошибку вам может внести сама IDE, если быть невнимательным. Пусть у вас такой Java-код:
void processList(boolean flag, List<String> list) { if(flag) { if(list.isEmpty()) return; if(list.get(0).equals("foo")) { System.out.println("...some long processing..."); // ... many lines of code } } else { if(list.size() < 3) return; if(list.get(0).equals("bar")) { // курсор здесь System.out.println("...another long processing using "+list.get(0)); // ... many lines of code } } }
С этим кодом всё нормально, ошибок нет. Вы его когда-то написали целиком с нуля, а так как вы профессиональный программист, то ошибок вы не допускаете. Но посмотрев на код уже после написания, вы замечаете, что как-то
list.get(0)повторяется в соседних строчках, некрасиво. Надо бы в переменную вынести. Вы активируете соответствующий рефакторинг в IDE, встав на это выражение. IDE вас спрашивает: «вам только это вхождение заменить на новую переменную или все?» Вы, естественно, говорите, все, и IDE генерирует такой код:
void processList(boolean flag, List<String> list) { String firstElement = list.get(0); if(flag) { if(list.isEmpty()) return; if(firstElement.equals("foo")) { System.out.println("...some long processing..."); // ... many lines of code } } else { if(list.size() < 3) return; if(firstElement.equals("bar")) { System.out.println("...another long processing using "+ firstElement); // ... many lines of code } } }
И код стал некорректным, потому что было ещё одно вхождение
list.get(0)в другой ветке и IDE его тоже вынесла в переменную, создав её до необходимых проверок на длину списка. Если слишком довериться IDE и не обратить внимания на то, что она сделала, можно здорово обжечься. Я недавно написал диагностику, которая отлавливает статически такой код. В нашем проекте нашлось несколько мест, где он появился именно в результате применения рефакторинга.
EvgeniyRyzhkov
26.04.2017 17:09+3Классный пример, Тагир! Хорошо иллюстрирует ситуацию, почему автоматическое исправление «в лоб» не всегда правильно. Ведь многие предлагают, чтобы анализаторы сами правили ошибки.
lany
26.04.2017 17:53+1Правильно, я тоже предлагаю. Надо просто понимать, что автоматический исправлятор тоже может накосячить. Голову отключать никогда не надо и весь свой код перечитывать перед коммитом обязательно. Ну и статический анализ использовать — он заметит то, чего вы не заметите :-)
vesper-bot
Да об обычный
if (a=b)вместоif (a==b)сколько копий сломано, что уж говорить о чем-то более сложном.Jef239
Тот, кто отключил диагностику этого случая в компиляторе — сам себе злобный буратино.
Впрочем, действительно есть люди, которым обязательно надо заплатить килобаксы, чтобы они хотя бы прочли диагностику.