Comments 41
Было бы интересно узнать что в PVS-Studio есть, чего нет в анализаторе IDEA.
Плохая идея сравнить IDEA и PVS-Studio, так как это инструменты разного типа. IDEA это productivity tool, а PVS-Studio это классический статический анализатор кода. PVS-Studio это подробная документация, различные варианты интеграции в CI, интеграция с SonarQube, классификация предупреждений согласно CWE, возможность генерации полных HTML отчётов (включающий код), механизм массового подавление предупреждений для внедрения инструмента в большие старые проекты и так далее.
А никто не просил сравнивать IDEA целиков, просили сравнить ее анализатор. Это вполне сравнимые вещи (да, хотя бы и по возможности интеграции в CI например). Все что вы перечисляете — это вторичные показатели, первичные же — это число найденных анализатором проблем (в том числе ложных).
Все что вы перечисляете — это вторичные показатели, первичные же — это число найденных анализатором проблемНе согласен, это вовсе не вторичные показатели, а часто как раз первичные. Если анализ неудобно использовать и трудоёмко внедрить в большой проект, то нет смысла обсуждать диагностики. Это не означает, что диагностики не важны. Однако, подходить вот так в лоб к сравнению, это плохая идея. К сожалению, более подробный ответ тянет на отдельную статью и думаю я со временем ей займусь. Спасибо, что подняли эту тему.
P.S.: Почему мы не пишем о сравнении PVS-Studio с другими статическими анализаторами кода.
С другой стороны, вот я пользуюсь idea. Их встроенный анализ находит мои ошибки в процессе написания кода. Что именно мне может дать pvs?
Мне кажется в такой формулировке этот вопрос имеет смысл.
Поделюсь своим небольшим опытом: такую ошибку idea не видит, а pvs увидел:
int[] arr = new int[4];
for (int i = 0; i < 5; i++) {
arr[i] = i;
}Я бы заменил этот цикл стримом (если это Java 8). Ну или другой конструкцией, где такие и похожие ошибки вообще сделать нельзя. К сожалению, такие вещи пока не видит ни один анализатор, хотя идея и пытается подсказывать что-то (но обычно довольно бесполезные вещи, типа «замените вот эту лямбду ссылкой на метод» — а я предпочитаю именно наоборот).
такие вещи пока не видит ни один анализаторНе совсем понял смысл фразы — как раз PVS это видит v557 Array overrun is possible. (Примера для Java сходу не нашёл).
PS: Сам я перешёл на котлин в котором такую ошибку сложнее сделать.
val arr = IntArray(4)
for(i in arr.indices) {
arr[i] = i
}В смысле — анализатор видит проблему, но не может предложить решение в виде замены на другую конструкцию. Массив — на стрим.
вы тут немного смешиваете, анализатор находит потенциально проблемные места, не его задача предлагать решение проблемы. «Замена, на другую конструкцию» это уже рефакторинг, что как бы немного за пределами ответственности анализатора.
По моему это может сказаться на производительности, а во вторых как бы вы переписали цикл из примера выше на стрим?
На производительности — может конечно. Стримы тут не обязательны, хотя и возможны: IntStream.range(...) например. Речь как бы не о том, на что конкретно заменить — речь о том, что встроенный анализатор IDEA не просто ищет проблемы, а иногда и предлагает замены. Поэтому параметру отдельный анализатор без таких возможностей будет уступать.
Что именно мне может дать pvs?Запустите и как раз увидите, что найдёт PVS-Studio, что ещё не находит IDEA.
Для этого стоило бы дать начальству понять зачем я пытаюсь протащить новый софт во внутреннюю сеть))
На самом же деле пользователем идеи не нужно именно сравнение анализаторов, никто же не собирается менять ide. Им (нам) только нужно дать понять, что во всех этих телодвижениях есть профит. То есть, что ваше кунг-фу сможет подсветить какие-нибудь баги которые у нас ещё не подсвечены.
>Если анализ неудобно использовать
Ну, по этому показателю любой отдельный анализатор сливает встроенному в IDEA по определению. А если учесть автоисправлялку — то и подавно.
Я вполне могу понять ваши мотивы не сравнивать, но мои мотивы как разработчика очень простые — если IDEA находит большую часть проблем, то зачастую мне невыгодно внедрять что-то еще, потому что это тоже работа, и она стоит денег и требует времени (возможно, при внедрении в CI — времени других людей). И если встроенный в IDE анализатор достаточно хорош — сразу возникает вопрос, а стоит ли внедрение чего-то еще усилий?
Ну, по этому показателю любой отдельный анализатор сливает встроенному в IDEA по определению. А если учесть автоисправлялку — то и подавно.
Я вполне могу понять ваши мотивы не сравнивать, но мои мотивы как разработчика очень простые — если IDEA находит большую часть проблем, то зачастую мне невыгодно внедрять что-то еще, потому что это тоже работа, и она стоит денег и требует времени (возможно, при внедрении в CI — времени других людей). И если встроенный в IDE анализатор достаточно хорош — сразу возникает вопрос, а стоит ли внедрение чего-то еще усилий?
Правильно я понимаю, что все ваши разработчики используют только IDEA, причём настроенную одинаковым образом?
Если да, то это хорошо, и вы молодцы. Но не было ли, что кто-то по невнимательности/лени/незнанию, всё равно закладывал баг в систему контроля версий, который вы вдруг потом обнаруживали уже на своей машине благодаря подсветке в IDEA? Если такое было, то это повод всё равно думать про CI.
Если нет, то вообще нельзя говорить, что в проекте используется статический анализ кода.
Если да, то это хорошо, и вы молодцы. Но не было ли, что кто-то по невнимательности/лени/незнанию, всё равно закладывал баг в систему контроля версий, который вы вдруг потом обнаруживали уже на своей машине благодаря подсветке в IDEA? Если такое было, то это повод всё равно думать про CI.
Если нет, то вообще нельзя говорить, что в проекте используется статический анализ кода.
Насчет все — ну тут ответ «почти». Остались одиночки на эклипсе, для которых есть сонар (и он в CI), и у них обычно другие роли, нежели писать код ежедневно.
Что до аргументов за анализ в рамках CI, одинаковый для всех и обязательный — то я с ними заранее согласен. Как раз идеевский анализатор прикрутить к CI или очень сложно, или вообще нельзя. Да и у сонара в его текущем виде, как он у нас используется, на мой взгляд слишком много ложных, сложно отключаемых срабатываний. Условно — у нас в проекте есть параметры, которые называются passwordAlias, и это не пароль ни разу. И попробуйте объяснить сонару, что не надо ругаться на эти названия — проще отключить сонар ;)
Что до аргументов за анализ в рамках CI, одинаковый для всех и обязательный — то я с ними заранее согласен. Как раз идеевский анализатор прикрутить к CI или очень сложно, или вообще нельзя. Да и у сонара в его текущем виде, как он у нас используется, на мой взгляд слишком много ложных, сложно отключаемых срабатываний. Условно — у нас в проекте есть параметры, которые называются passwordAlias, и это не пароль ни разу. И попробуйте объяснить сонару, что не надо ругаться на эти названия — проще отключить сонар ;)
Добавьте PVS-Studio в SonarQube. Вам должно понравиться.
Общаешься с людьми на Хабре — у все все настроено, везде автоматически все работает, тестами все покрыто…
Вот только статей про ошибки в программах меньше не становится почему-то.
Вот только статей про ошибки в программах меньше не становится почему-то.
Лично я ничего такого не говорил. Вопрос был про идею, и в этом случае у нас ее реально 99% — но это лишь один проект, а даже например не отдел. И сонар с CI конечно тоже есть — но это не новость, я думаю это у многих.
Ну и потом, у нас вообще основной инструмент спарк, и покрыть приложение юнит тестами вообще почти не реально. А интеграционными очень сложно.
Статический анализ есть, но сонар пока не нашел у нас ничего серьезного — но это не значит, что этого серьезного не было.
Что же до реальных источников ошибок, то я могу сходу назвать один — это неопределенности во внешних условиях, в постановке задачи, и т.п. И во внешних по отношению к программе данных. Статический анализ это далеко не всегда может увидеть.
Ну и потом, у нас вообще основной инструмент спарк, и покрыть приложение юнит тестами вообще почти не реально. А интеграционными очень сложно.
Статический анализ есть, но сонар пока не нашел у нас ничего серьезного — но это не значит, что этого серьезного не было.
Что же до реальных источников ошибок, то я могу сходу назвать один — это неопределенности во внешних условиях, в постановке задачи, и т.п. И во внешних по отношению к программе данных. Статический анализ это далеко не всегда может увидеть.
Как раз идеевский анализатор прикрутить к CI или очень сложно, или вообще нельзя.
Первый комментарий к статье «Запускаем инспекции IntelliJ IDEA на Jenkins» именно от вас, а говорите «нельзя».
В статье рассказно, как регистрировать PVS-Studio…
Здравствуйте.
Ожидается ли сравнение функциональности с ближайшим собратом ru.wikipedia.org/wiki/FindBugs?
Ожидается ли сравнение функциональности с ближайшим собратом ru.wikipedia.org/wiki/FindBugs?
FindBugs умер много лет назад.
И на его место пришел SpotBugs
Да, со SpotBugs можно сравниться. Но не хочется. Кстати, ошибки в нём мы находили.
Можно один вопрос, ваш анализатор работает с исходным кодом, а SpotBugs (и FindBugs) с байткодом?
Да, PVS-Studio работает с исходным кодом. FindBugs анализирует не исходники, а байт-код. Как я понимаю, SpotBugs, аналогично работает с байт-кодом.
А ваш проект с помощью с SpotBugs я проверить не могу, из-за лицензии?
А для Python PVS-Studio не планируется?
Многие даже не слышали про анализатор, а кто слышал, тот мало знаком со всеми его возможностями.
В статье НЕ рассказано про возможнлсти анализатора. Предположим я не знаю нужен мне авто-анализатор, или проще и дальше ручками статанализ делать, как эта статья поможет ответить на этот вопрос?
Ну, на самом деле были и другие статьи, так что просто возьмите да почитайте. Как раз с ответами на эти вопросы (ну, в какой-то степени). Я лично даже слегка удивился, когда появилась статья вот такая, с описанием базовых процессов, потому что про Java анализатор в общем-то давно уже известно, и примеры анализа уже были.
А в чем разница между созданием плагинов для IDEA и CLion/Rider если экосистема IDE одна? Когда будут плагины для указанных IDE?
Кстати, а что с поддержкой других языков? IDEA в какой-то степени работает с груви, котлином и скалой. Можно ли искать проблемы и в них тоже? Грубо говоря — можно ли на сегодня проверить что-то типа Apache Spark? И было бы очень интересно посмотреть на результаты проверки чего-то большого, и достаточно древнего, скажем Hadoop.
P.S. Насколько я понимаю, из ответа на другой вопрос следует, что скорее всего нет, так как работа происходит с исходным кодом, а он тут сильно другой.
P.S. Насколько я понимаю, из ответа на другой вопрос следует, что скорее всего нет, так как работа происходит с исходным кодом, а он тут сильно другой.
Sign up to leave a comment.
Знакомство со статическим анализатором PVS-Studio для Java