Все правильно вы поняли, на мой взгляд статический анализ должен показывать что сломалось на данной итерации, и, по всей видимости, этот взгляд несколько отличается от взглядов ваших клиентов.
Если это первый запуск, ок, нам вываливается тысячи сообщений — надо заниматься настройками инструмента и решением проблем которые есть в коде.
P.S. Хочу подчеркнуть, что возможность на лету включать/выключать какие-то сообщения очень важна, когда речь идет о большом проекте. Его анализ может выполняться часы. И для него не вариант режим «поменяли настройки, перезапустили, посмотрели что получилось».
Я не говорю что существующий функционал бесполезен, если есть благодарные клиенты, то тут не должно возникать сомнений. Я о том, что для меня инструмент, использование которорого нельзя автоматизировать, не является _полноценным_ инструментом.
Позвольте обобщить мои рассуждения на тему:
Какой бы вы хотели видеть такую утилиту?
— Я не хочу перед каждым сабмитом запускать GUI чтобы посмотреть наличие или отсутствие ошибок.
— Я хочу без лишних телодвижений засабмитить код.
— Я хочу чтобы cruisecontrol (или подобная система) перед построением запустила статический анализ и прислала мне письмо, если что-то не так.
Если надо недорогая борда с ARM архитектурой на борту, обратите взор на Stellaris Launchpad от TI.
За $10 (пересылка бесплатно) получаем 2 камня на борде + serial «кабель» 5V5 -> 3V2
Ну, меня как разработчика интересует только случаи, когда что-то пошло не так. Логи без полезной нагрузки вида «я тут проверил этот файл, все нормально, а сейчас я перейду в другую директорию» не нужны.
False positive сообщения отключаются специальным типом комментария, однажды получив сообщение и приняв решение что это именно этот случай, больше этого сообщения для конкретной строки кода не видишь.
Я не знаю критериев серьезности статического анализа, для меня это автоматический процесс перед сабмитом в рамках указанных утилит. Запустил, посмотрел, что ошибок нет, и забыл.
Ваши подозрения немного не верны. В регулярном режиме перед каждым сабмитом запускаю target в основном makefile проекта, который, в свою очередь, вызывает cppcheck и cpplint для всех файлов.
Позвольте пояснить. Я, как программист под nix платформы, хотел бы вобще не видеть ни каких GUI утилит, а использовать простой путь вызова анализатора, вида:
pvs_check my_source1.c
Выше приведен, псевдо-пример cmake конфига, который поможет мне в этом. После написания такого конфига, вызов статического анализатора будет прост как никогда.
Под Линукс:
cmake .
make pvs_check
Под Виндовс:
cmake .
make pvs_check
devenv pvs_check.sln
Какой бы вы хотели видеть такую утилиту?
Ответ на вопрос следующий:
— Простейшее использование без лишних телодвижений (написал конфиг и забыл);
— Кросплатформенность;
— Достаточно списка ошибок и указания на место в коде, где эта ошибка случилась;
— Не нужна замена vim моего любимого редактора.
Даже не представляю, поскольку не представляю процесс производства солнечных батарей. :)
Но готов, в качестве спонсорской помощи, купить вышеуказанный экземпляр за $200 + необходимую для опытов пасту для полировки.
Если кто-то из компаний или частных лиц имеет желание спонсировать мои проекты
Если со временем получится полировать, можно будет пробовать делать солнечные батареи (а из монокристаллического кремния они получаются довольно эффективные).
В качестве спонсорской помощи готов купить первую самостоятельно сделанную солнечную батарею с автографом автора.
Хочется услышать подробнее про «количество усилий» и как расчитываете потенциальную отдачу. Второе даже интереснее. Какие-то исследования проводились или решили на уровне «мне кажется не пойдет эта тема»?
А можно подробнее про «экономику»?
По работе сталкивалсясь с STB устройствами и промышленными компьютерами с Линуксом на борту, для статических проверок использовал cppcheck и cpplint от google. PVS-Studio пришелся бы к столу.
Если это первый запуск, ок, нам вываливается тысячи сообщений — надо заниматься настройками инструмента и решением проблем которые есть в коде.
Я не говорю что существующий функционал бесполезен, если есть благодарные клиенты, то тут не должно возникать сомнений. Я о том, что для меня инструмент, использование которорого нельзя автоматизировать, не является _полноценным_ инструментом.
Позвольте обобщить мои рассуждения на тему:
— Я не хочу перед каждым сабмитом запускать GUI чтобы посмотреть наличие или отсутствие ошибок.
— Я хочу без лишних телодвижений засабмитить код.
— Я хочу чтобы cruisecontrol (или подобная система) перед построением запустила статический анализ и прислала мне письмо, если что-то не так.
За $10 (пересылка бесплатно) получаем 2 камня на борде + serial «кабель» 5V5 -> 3V2
cppcheck --enable=all --error-exitcode=1 -q --inline-suppr <список файлов>0 строк, если все хорошо.
cpplint --filter=-whitespace,-build/include,-legal/copyright,-runtime/references,-build/header_guard,-build/namespaces,-readability/streams <список файлов>N строк + 1, где N — число файлов, + 1 — общее количество ошибок
За пару-тройку недель работы всплывает от 0 до 2 ошибок.
Вы так и не сказали критериев серьезности статистического статистического анализа. Как я понимаю, то, что делаю я, это _не_ серьезный анализ, верно?
False positive сообщения отключаются специальным типом комментария, однажды получив сообщение и приняв решение что это именно этот случай, больше этого сообщения для конкретной строки кода не видишь.
Я не знаю критериев серьезности статического анализа, для меня это автоматический процесс перед сабмитом в рамках указанных утилит. Запустил, посмотрел, что ошибок нет, и забыл.
pvs_check my_source1.cВыше приведен, псевдо-пример cmake конфига, который поможет мне в этом. После написания такого конфига, вызов статического анализатора будет прост как никогда.
Под Линукс:
cmake .make pvs_checkПод Виндовс:
cmake .make pvs_checkdevenv pvs_check.slnОтвет на вопрос следующий:
— Простейшее использование без лишних телодвижений (написал конфиг и забыл);
— Кросплатформенность;
— Достаточно списка ошибок и указания на место в коде, где эта ошибка случилась;
— Не нужна замена
vimмоего любимого редактора.А еще не особо понятно зачем «полноценный» редактор кода в этой утилите, да и еще жестко привязанный к Win32 компоненте.
Тут есть потенциальные грабли, когда в разросшийся код будет добавлятся новая платформа. Лучше сразу приучить себя писать конструкции вида:
Но готов, в качестве спонсорской помощи, купить вышеуказанный экземпляр за $200 + необходимую для опытов пасту для полировки.
В качестве спонсорской помощи готов купить первую самостоятельно сделанную солнечную батарею с автографом автора.
По работе сталкивалсясь с STB устройствами и промышленными компьютерами с Линуксом на борту, для статических проверок использовал cppcheck и cpplint от google. PVS-Studio пришелся бы к столу.