Comments 24
Кто подскажет что то ( хорошо бы с триалом ) для статического анализа проекта под линукс.
Пробовал натравливать просто на папку Cppcheck виндовый — в основном указал на неиспользуемые переменные и постфиксные инкременты, нашел один баг который совсем недавно внесли в проект — но уверен его бы нашли уже при выкладке. Хочется напустить на проект что то серьезноею. Собираем cmake — ом если это важно.
Cppcheck будет более эффективен с корректно настроенными параметрами. Последнего удобно добиваться используя опцию --check-config.

P.S. Проект под Linux, что то мне подсказывает, удобнее проверять под Linux'ом, тем более, что, во-первых: cppcheck кросс-платформенный, а во-вторых: для некоторых дистрибутитов он может быть установлен из репозиториев.
Попробуйте статический анализатор clang-а. Без проблем прикручивается к системе сборки (в моём случае CMake), просто подменой компилятора. И это FOSS, не нужны никакие триалы. И развивается ж активно.
Пробовали — понравилось, вот только ниасилили прикрутить его к Jenkins'у…
Нет. Просто люди, наконец, узнали про PVS-Studio и инструмент им начал нравиться. Автор недавно попросил пробный ключ, мы ему дали. А теперь вот написал стать. Благодарю его за это!
UFO landed and left these words here
Любой желающий может обратиться за ключиком и написать свой беспристрастный обзор.
UFO landed and left these words here
Что вы считаете рекламой? Мне стало интересно попробовать еще один анализатор, я попросил пробный ключ на две недели, автор ключ предоставил и попросил оставить отзыв. Никакой другой заинтересованности у меня не было.

А то, что анализатор не подвисает на 18 минут, а показывает адекватный прогресс-бар — так что с того, что мне это реально понравилось? Будто бы вы никогда не видели псевдо-прогресс-баров я-ля «виндоуз виста». Компилятор студии, кстати, прогресс-бар не показывает почему-то.
Гланый недостаток PVS-Studio это то что она работает только с студией и из под винды
Гланый недостаток PVS-Studio это то что про нее говорят слишком много и абсолютно однообразно.
Как я уже написал выше — что вы считаете рекламой и как отличаете ее от обзора?
Ну как, очевидно же, если ни разу не использовано выражение «полное гавно» — значит реклама. :)
>>> (отмечу только отслеживание состояния от билда к билду – сколько проблем было исправлено, сколько осталось, а сколько добавилось, а также удобные отчеты),

А в чем польза отслеживания? Не очень понятно, приведите примеры.
Беру я проект, уже существующий, запускаю анализатор, нахожу, скажем, 20 проблем. Это отправная точка. Раздаю проблемы ответственным, проходит какое-то время, пишется новый код, исправляются существующие проблемы… Делается новый билд (и проверка анализатором) — и по-моему, вполне естественное желание: увидеть, сколько было исправлено из первых 20 найденных, а сколько было внесено новых. Нет?

Иначе, если я вижу только цифру 20 после второго билда, то как я могу увидеть, это были исправлены старые и добавлены новые, или просто остались старые?
Так вот и не ясно. Казалось бы при регулярном использовании анализатора количество обнаруживаемых ошибок должно стремиться к нулю (понятно, что из-за нового кода, оно никогда не будет именно ноль). Но какую информацию дает знание что не просто в проекте 20 ошибок, а 10 старых и 10 новых? Я хочу понять, как пользоваться этой информацией.
Вот допустим я сам запустил анализатор, нашел 20 проблем и стал их одна за одной исправлять. Исправил одну из них и хочу посмотреть, исправил ли? Пересобрал проект, запустил анализатор — получил опять 20. Что мне делать теперь? Вчитываться заново в описания всех 20, чтобы понять, что произошло — я исправил одну и добавил другую, или же почему-то не исправил первую?

Если однажды на проекте будет достигнуто состояние «ни одного предупреждения» — тогда да, необходимость в трекинге не столь важна. Но — насколько это реально на более-менее серьезном проекте, особенно если анализатор применяется не регулярно, а эпизодически и не с самого начала?

Также трекинг полезен для ПМ для контроля исправления найденных проблем назначенными для этого ответственными. Как это делать без трекинга? Раскидал ПМ все 20 найденных проблем по людям, решил через неделю посмотреть, как эти 20 проблем были закрыты — и что? Что он должен сделать без трекинга? Вносить каждую проблему по отдельности в багтрекинг и следить там? Можно, но все же дополнительные усилия. А мог бы прямо в результатах следующего анализа увидеть.
У нас есть внутренний инструмент, который делает очень похожую вещь. Он берет два лога, сравнивает их и пишет, какие сообщения добавились, какие пропали.

Но что делать в случае, если не просто сообщение пропало/добавилось, а сдвинулись строки из-за редактирования файла?

Была ошибка C111 в строке 43 в старом логе. В новом логе в строке 43 ошибки нет, но есть такая же ошибка C111 в строке 91. Наш инструмент скажет, что старая ошибка пропала, а новая добавилась. Но ведь это может быть просто в начало файла код функции вставили.

Klocwork как поступит в этом случае?
У них (у Klocwork) привязка более точная вроде бы, не к строкам, а к классам-функциям как минимум. Во всяком случае, на сдвиги строк он правильно реагировал, когда, например, часть кода удалялась или добавлялась. Подробно я этот момент не тестировал — насколько точно он определяет стар

Похожая задача стоит перед сравнивалками файлов. И например Winmerge часто неправильно сдвиг определяет (особенно если сдвиг вместе с модификацией), а Araxis делает это в разы лучше (но за деньги).
Only those users with full accounts are able to leave comments. Log in, please.