Не знаю, что здесь ответить. Не занимались какой-то такой статистикой.
P.S. Желающие могут брать SonarSource, прицепить наш анализатор и настроить графиков и зависимостей на любой вкус.
Если вам интересны параметры нашей системы, то там 135 тысяч строк и 10 человеко-лет.
Теперь всё понятно. У вас очень маленький проект. И да, в таком проекте использование статического анализатора не является по настоящему нужным: низкая плотность ошибок, возможность обозреть весь проект и осознавать, как он работает.
Числа для сравнения. Весь проекте PVS-Studio мы считаем небольшим. А ядро C++ анализатора PVS-Studio вообще маленьким. Так вот, маленькое C++ ядро PVS-Studio содержит 225884 строк кода.
Это, пожалуй, пограничный размер, когда ещё можно обходиться без статического анализа кода. Мы используем инструменты для анализа своего кода (было бы странно для нас не использовать :). Но повторюсь, процесс развития проекта и его качество ещё можно контролировать вручную. Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.
Помог, не помог… С удовольствием пользуются несколько лет PVS-Studio. Огромный проект на Visual C++ и никакой речи даже нет о возможностях там попробовать GCC или что-то ещё.
Вы усиленно ссылаетесь здесь и в других комментариях на статью "Проверяем исходный код плагина PVS-Studio с помощью PVS-Studio" и говорите «ага, я же говорил, что мало находится». Есть 3 момента, о которых Вы не подумали или сознательно не замечаете.
Плагин для Visual Studio, это маленькая программа, там просто негде взяться сотням ошибкам.
В маленькой программе и плотность ошибок меньше.
Суть статического анализа в регулярных запусках. Мы бы возможно сократили время на поиск некоторых ошибок, если использовали анализатор сразу. Но для такой маленькой программы как плагин об этом и рассуждать особенно смысла нет. Можно вполне обходиться без статического анализа, что мы и делали. Эта статья писалась не для рекламы, а исключительно для того, чтобы наконец было отвечать на вопрос, который уже вызывает зубную боль, проверяли ли мы PVS-Studio с помощью PVS-Studio.
Сейчас случайно наткнулся на просторах интернета на интересное обсуждение. В общем, количество предупреждений, выдаваемых PVS-Studio постепенно растет и один неравнодушный замечает, что "It seems that bugfixing is going wrong..." :)
Это я просто на примере хочу ещё раз продемонстрировать, что анализатор может показывать менеджеру о некоторых процессах, происходящих в проекте. Как я писал в статье, анализатор кода это не только инструмент для поиска ошибок, но и один из инструментов для контроля и слежения за происходящим. Он позволяет держать менеджеру руку на пульсе проекта.
Я про php и зенд-студию ничего не знаю. Но у меня крутится в голове: быть может у вас просто нормального анализатора не было? :)
Например, мы недавно проверяли проект PascalABC.NET с помощью SonarC# и PVS-Studio. И по нашему мнению, дело обстоит так:
Не будем точно считать проценты ложных срабатываний, так как мнение может быть предвзятым. Но все равно понятно, что осилить 700 сообщений проще, чем 1800. И ясно, что 1800 может сильно утомить и испортить аппетит к статическим анализаторам.
Но ведь и нет никакой проблему убирать новые ложные срабатывания. По крайней мере, если говорить о PVS-Studio.
Для этого есть масса способов. Например, можно изменить код. При этом как правило он становится проще и понятней, причем не только анализатору, но и коллегам. Очень часто анализатор выдаёт предупреждения на код, который написан в стиле «смотрите, как я могу».
Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа, если там сгенерированный код или какие-то тесты, аномальные с точки зрения анализатора: if (A == A) для проверки реализации оператора ==.
Но до определенной степени, когда ложных срабатываний накапливается слишком много — разумнее игнорить, чем обращать внимание.
Статический анализатор используется неправильно. Они не должны накапливаться! Полная аналогия с предупреждениями компилятора — их не должно быть. Иначе вступает в силу теория разбитых окон.
Тулза особенно полезна на огромных проектах, как я вижу из статей.
Да, анализатор становится всё полезнее с ростом проекта. Чем больше проект, тем больше плотность ошибок. 13k — это очень маленький проект.
Таблица. Книга Стива Макконнелла «Совершенный код». Размер проекта и типичная плотность ошибок. В книге указаны источники данных: «Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).
Таким образом, есть шанс, что в таком проекте вообще не будет ошибок. :)
«За такой вершиной айсберга» у меня работа системы 365 на 24 в течение 15 лет.
Не берусь конечно утверждать и не хочу никого обидеть, однако выскажу своё мнение. Когда заходит речь о системах, которые работают 10 лет подряд, то потом выясняется, что речь идёт о весьма и весьма простых программах, которые действительно можно написать без ошибок. Ведь закон экспоненциального роста глючности никто не отменял. А в системах, работающих годами слабый процессор, мало памяти и как следствие маленькие программы. В них часто часто память выделяется только один раз при запуске. Нет выделений памяти и уже нет массы проблем и ошибок.
Процентов 50 предупреждений компилятора — это реальные баги, которые надо править. Была бы у статических анализаторов эффективность хотя бы 5% — цены бы им не было.
Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
Всё просто. Если ошибка стоит 20$, то этому проекту не нужен статический анализатор. Впрочем, это какой-то волшебный проект. В настоящем проекте цена ошибки на порядке выше.
В любом случае, если картина такая, как Вы описали, действительно продать анализатор невозможно. Однако есть другой класс проектов, где ошибка или простой программы выливается в большие деньги. Я, например, знаю случай, когда анализатор PVS-Studio нашел ошибку возрастом в 2 года (там было что-то в духе x*(10/3) из-за которой клиентам автоматически выставлялась неправильная заниженная цена не некоторую группу товаров. Причем, программист рассказал мне по секрету, что побоялись даже доложить начальству об этой ошибке и просто решили втихомолку её исправить.
Еще я знаю случай, когда команду разработчиков несколько раз катали на самолёте на другую сторону земного шара, чтобы они сидели и ждали, когда система опять упадёт, чтобы на месте найти наконец и исправить злосчастный баг, который проявляет себя, как только программисты улетают домой. Оказался неинициализированный член класса.
Я к тому, что ошибки бывают очень дорогие, но при этом до безобразия простые и могли быть легко выявлены анализатором кода. И кстати, менеджеров таких проектов, в отличии от программистов, как-то даже не надо убеждать, что ошибки, это плохо и надо постараться сразу найти их как можно больше.
ВО всем вашем блоге — 1-2 примера про то, что у человека был реальный баг, он запустил PVS-studio и баг нашелся.
Ну что делать, если нам редко сообщают об интересных найденных ошибках. Да и о большинстве мы всё не можем написать. Почти у всех наших клиентов код закрыт, и они не хотели бы чтобы мы приводили примеры из их кода. Не писать же статью в духе. Компания X нашла ошибку, Y, в коде Z, но X/Y/Z мы не покажем. :)
Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.
Потому и запускают бесплатный cppcheck редко, что затраты на его запуск не оправдываются.
Запускайте что-то посерьезней и поудобней. Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно.
Причина простая: основные баги — в алгоритмах. В работе аналитиков. математиков. постановщиков, алгоритмистов. А багов при кодировании — не так много. А основной эффект от статического анализатора — это введение в заблуждение менеджеров.
Большое спасибо за ваш комментарий. Благодаря ему моя статья становится что ли более достоверной. А то получается, что я описываю неких абстрактных людей. А Вы как бы воплощаете заблуждения в реальность. :)
Вот только бубен стоит 200-300 рублей, а PVS-Studio — немерянные килобаксы. Стоит ли их тратить на технологию с «недоказанной эффективностью» — непонятно.
Не отпугивайте народ :). Наши цены очень даже скромные по сравнению с Coverity, Klocwork. Мы сознательно выбрали среднюю ценовую нишу и живём в ней. Мы тем, кому PC-Lint уже кажется устаревшим/простоватым/неудобным/не умеющий C++14 (а новый они вот уже 3 года делают на основе Clang, но пока всё никак), а цены на Coverity/Xyz уже перебор.
Причем, в плане диагностик мы уже наступаем на пятки Coverity/Klocwork. Так что соотношение результат/цена весьма привлекательно. Покупайте наших слонов!
Я за C++ скажу. По моему субъективному мнение (а в этом вопросе мне можно доверять), разницы между качеством кода C и C++ нет. И там, и там есть опечатки и и.д. Да, в C++ стало лучше с управлением памяти, зато и способов накосить стало больше. Например, можно написать std::unique_ptr p(new A[3]);. Т.е. выделяем массив, а уничтожаем потом как один элемент.
Иногда попадаются очень качественные C++ проекты, написанные на всяких контейнерах, с применением всяких хороших техник и т.п. И там очень сложно найти ошибку (пример). Но так ведь есть и очень качественные C проекты (пример).
P.S. Желающие могут брать SonarSource, прицепить наш анализатор и настроить графиков и зависимостей на любой вкус.
Числа для сравнения. Весь проекте PVS-Studio мы считаем небольшим. А ядро C++ анализатора PVS-Studio вообще маленьким. Так вот, маленькое C++ ядро PVS-Studio содержит 225884 строк кода.
Это, пожалуй, пограничный размер, когда ещё можно обходиться без статического анализа кода. Мы используем инструменты для анализа своего кода (было бы странно для нас не использовать :). Но повторюсь, процесс развития проекта и его качество ещё можно контролировать вручную. Если же речь о 135000, то тут конечно сложно продемонстрировать полезность инструментов статического анализа.
Это я просто на примере хочу ещё раз продемонстрировать, что анализатор может показывать менеджеру о некоторых процессах, происходящих в проекте. Как я писал в статье, анализатор кода это не только инструмент для поиска ошибок, но и один из инструментов для контроля и слежения за происходящим. Он позволяет держать менеджеру руку на пульсе проекта.
Например, мы недавно проверяли проект PascalABC.NET с помощью SonarC# и PVS-Studio. И по нашему мнению, дело обстоит так:
Не будем точно считать проценты ложных срабатываний, так как мнение может быть предвзятым. Но все равно понятно, что осилить 700 сообщений проще, чем 1800. И ясно, что 1800 может сильно утомить и испортить аппетит к статическим анализаторам.
Для этого есть масса способов. Например, можно изменить код. При этом как правило он становится проще и понятней, причем не только анализатору, но и коллегам. Очень часто анализатор выдаёт предупреждения на код, который написан в стиле «смотрите, как я могу».
Можно подавлять точечно, используя комментарии. Можно использовать базу разметки. Можно исключить файлы из анализа, если там сгенерированный код или какие-то тесты, аномальные с точки зрения анализатора: if (A == A) для проверки реализации оператора ==.
Да, анализатор становится всё полезнее с ростом проекта. Чем больше проект, тем больше плотность ошибок. 13k — это очень маленький проект.
Таблица. Книга Стива Макконнелла «Совершенный код». Размер проекта и типичная плотность ошибок. В книге указаны источники данных: «Program Quality and Programmer Productivity» (Jones, 1977), «Estimating Software Costs» (Jones, 1998).
Таким образом, есть шанс, что в таком проекте вообще не будет ошибок. :)
Процент сообщений анализатора PVS-Studio, с которыми стоит что-то сделать:
В любом случае, если картина такая, как Вы описали, действительно продать анализатор невозможно. Однако есть другой класс проектов, где ошибка или простой программы выливается в большие деньги. Я, например, знаю случай, когда анализатор PVS-Studio нашел ошибку возрастом в 2 года (там было что-то в духе x*(10/3) из-за которой клиентам автоматически выставлялась неправильная заниженная цена не некоторую группу товаров. Причем, программист рассказал мне по секрету, что побоялись даже доложить начальству об этой ошибке и просто решили втихомолку её исправить.
Еще я знаю случай, когда команду разработчиков несколько раз катали на самолёте на другую сторону земного шара, чтобы они сидели и ждали, когда система опять упадёт, чтобы на месте найти наконец и исправить злосчастный баг, который проявляет себя, как только программисты улетают домой. Оказался неинициализированный член класса.
Я к тому, что ошибки бывают очень дорогие, но при этом до безобразия простые и могли быть легко выявлены анализатором кода. И кстати, менеджеров таких проектов, в отличии от программистов, как-то даже не надо убеждать, что ошибки, это плохо и надо постараться сразу найти их как можно больше.
Для тех, кто не понял юмор. V501 есть у всех (FreeBSD, Clang, Far, Blender, GCC, Unreal Engine, Chromium, Qt, TortoiseSVN, ...)
Косвенным подтверждением эффективности анализатора и что он находит серьёзные ошибки, является то, что многие компании год из года продлевают лицензии. Это Жжжж не с проста.
Запускайте что-то посерьезней и поудобней. Например, можно настроить PVS-Studio чтобы он запускался ночью и отправлял письма тем, в чьём коде нашлось подозрительное место. Очень удобно.
Большое спасибо за ваш комментарий. Благодаря ему моя статья становится что ли более достоверной. А то получается, что я описываю неких абстрактных людей. А Вы как бы воплощаете заблуждения в реальность. :)
Не отпугивайте народ :). Наши цены очень даже скромные по сравнению с Coverity, Klocwork. Мы сознательно выбрали среднюю ценовую нишу и живём в ней. Мы тем, кому PC-Lint уже кажется устаревшим/простоватым/неудобным/не умеющий C++14 (а новый они вот уже 3 года делают на основе Clang, но пока всё никак), а цены на Coverity/Xyz уже перебор.
Причем, в плане диагностик мы уже наступаем на пятки Coverity/Klocwork. Так что соотношение результат/цена весьма привлекательно. Покупайте наших слонов!
Иногда попадаются очень качественные C++ проекты, написанные на всяких контейнерах, с применением всяких хороших техник и т.п. И там очень сложно найти ошибку (пример). Но так ведь есть и очень качественные C проекты (пример).
Добро пожаловать в реальный мир программирования. :) Думаю, дискуссия которая разворачивается, будет Вам необычно и интересна.