Comments 47
А мне вот интересно, если код полностью покрывать тестами перед написанием — такие ошибки все еще будут существовать? Также статический анализ врятли обнаружит логическую ошибку, а тест — запросто.
Ответ на вопрос с примерами: "Как статический анализ дополняет TDD".
Будут.
Одно другому не мешает.
Одно другому не мешает.
Ага, тогда такие ошибки переползут из кода приложения в код тестов :)
Тесты должны дополнять систему типов, там, где она не способна справиться, а не заменять её.
Тесты должны дополнять систему типов, там, где она не способна справиться, а не заменять её.
Да уж, количество и качество багов в примерах драйверов впечатляет!
Приятно что Вы начали охватывать новые IDE. Можно ли ожидать в дальнейшем поддержку Linux/Eclipse?
Мы относительно близки к этому. Например, мы экспериментировали с Wine. Заметка на эту тему: Запуск PVS-Studio на Linux возможен? Направление это не развивается больше по экономическим соображениям, чем по техническим. А вообще, мы постоянно развиваемся и со временем охватим что-то ещё. Например, мы незаметно поддержали проверку проектов на языке C++/CX (Windows Phone 8 и Windows Store проекты в Visual Studio 2012).
А можно подробнее про «экономику»?
По работе сталкивалсясь с STB устройствами и промышленными компьютерами с Линуксом на борту, для статических проверок использовал cppcheck и cpplint от google. PVS-Studio пришелся бы к столу.
По работе сталкивалсясь с STB устройствами и промышленными компьютерами с Линуксом на борту, для статических проверок использовал cppcheck и cpplint от google. PVS-Studio пришелся бы к столу.
Экономика проста. (Количество усилий на Linux-версии) / (потенциальная отдача) = (не очень привлекательное число). Конечно же я могу быть не прав.
Хочется услышать подробнее про «количество усилий» и как расчитываете потенциальную отдачу. Второе даже интереснее. Какие-то исследования проводились или решили на уровне «мне кажется не пойдет эта тема»?
На уровне «мне кажется».
Мы никогда не занимались настоящим исследованием этого вопроса, но есть четкое ощущение, что ничего хорошего из этого не выйдет. Я могу перечислить отдельные элементы, из которых складываются эти убеждения.
Мы были свидетелями мучений проекта, причиной которых являлось желание поддержать «парочку других платформ» без соответствующего увеличения штата сотрудников. Отчего-то программисты уверены, что поддержка других систем равнозначна возможности собрать проект другим компилятором на другой платформе. Это как раз, действительно, просто. Но абстрактная программа сама по себе никому не нужна. Нужно, чтобы она умела взаимодействовать с новым окружением, предоставлять адекватную для этой среды документацию, быть протестирована. Для неё должен быть создан дистрибутив и многое другое. В результате, работы надо проделать не чуть-чуть, а очень даже много. А потом всё это поддерживать. Думаю, поддержка каждой новой системы отнимает дополнительно увеличение штата (бюджета) на 10%-50%. Если этого не делать, то команда надорвётся.
Я уверен, что с анализатором кода, дополнительные затраты ресурсов будут велики. Сейчас мы не видим возможности быстро расширять штат. Таким образом, попытка поддержки новых платформ превратится в пшик. Просто не хватит сил сделать все хорошо. А плохо лучше и не делать.
Теперь про потенциальную пользу освоения, например, Eclipse. По отчету РУССОФТ процентное соотношение популярных инструментов разработки в 2012 году таково:
MS Visual Studio — 62%
Eclipse — 6 %
Конечно, привлечь ещё 6% программистов это замечательно. Но вот расходы при этом вырастут далеко не на 6%. Нужно будет разработать новый плагин. Без плагина консольная версия практически бесполезна. Нужно будет перерабатывать и расширять документацию. Потребуется создать новую базу open-source проектов, из которых построить соответствующую систему тестирования. И вообще всё это надо тестировать и поддерживать. Дистрибутив. Возможно, будут нюансы с распараллеливанием анализа. Альтернативная система хранения настроек (не реестр Windows). Ой, да много чего будет. Цена разработки PVS-Studio точно вырастет, более чем на 6%.
А теперь самое интересное. Потратив эти усилия, вовсе на значит, что продажи вырастут хотя бы на те же 6%. Linux/Open source сообщество очень неохотно приобретает лицензии. По крайней мере в плане инструментария. Они избалованы бесплатным программным обеспечением. И как результат, многие разработчики инструментария потихоньку сворачивают Linux версии. Я слышал о нескольких примерах, но уже забыл названия. Вспомнил только про «AQTime Linux Edition», которая теперь «AQtime Linux edition is no longer developed and supported». SmartBear Software как бы намекает нам…
Мы были свидетелями мучений проекта, причиной которых являлось желание поддержать «парочку других платформ» без соответствующего увеличения штата сотрудников. Отчего-то программисты уверены, что поддержка других систем равнозначна возможности собрать проект другим компилятором на другой платформе. Это как раз, действительно, просто. Но абстрактная программа сама по себе никому не нужна. Нужно, чтобы она умела взаимодействовать с новым окружением, предоставлять адекватную для этой среды документацию, быть протестирована. Для неё должен быть создан дистрибутив и многое другое. В результате, работы надо проделать не чуть-чуть, а очень даже много. А потом всё это поддерживать. Думаю, поддержка каждой новой системы отнимает дополнительно увеличение штата (бюджета) на 10%-50%. Если этого не делать, то команда надорвётся.
Я уверен, что с анализатором кода, дополнительные затраты ресурсов будут велики. Сейчас мы не видим возможности быстро расширять штат. Таким образом, попытка поддержки новых платформ превратится в пшик. Просто не хватит сил сделать все хорошо. А плохо лучше и не делать.
Теперь про потенциальную пользу освоения, например, Eclipse. По отчету РУССОФТ процентное соотношение популярных инструментов разработки в 2012 году таково:
MS Visual Studio — 62%
Eclipse — 6 %
Конечно, привлечь ещё 6% программистов это замечательно. Но вот расходы при этом вырастут далеко не на 6%. Нужно будет разработать новый плагин. Без плагина консольная версия практически бесполезна. Нужно будет перерабатывать и расширять документацию. Потребуется создать новую базу open-source проектов, из которых построить соответствующую систему тестирования. И вообще всё это надо тестировать и поддерживать. Дистрибутив. Возможно, будут нюансы с распараллеливанием анализа. Альтернативная система хранения настроек (не реестр Windows). Ой, да много чего будет. Цена разработки PVS-Studio точно вырастет, более чем на 6%.
А теперь самое интересное. Потратив эти усилия, вовсе на значит, что продажи вырастут хотя бы на те же 6%. Linux/Open source сообщество очень неохотно приобретает лицензии. По крайней мере в плане инструментария. Они избалованы бесплатным программным обеспечением. И как результат, многие разработчики инструментария потихоньку сворачивают Linux версии. Я слышал о нескольких примерах, но уже забыл названия. Вспомнил только про «AQTime Linux Edition», которая теперь «AQtime Linux edition is no longer developed and supported». SmartBear Software как бы намекает нам…
А C++ Builder какой процент? Просто мне кажется удивительным выбор данной среды. Я не знаю ни одного программиста, который бы использовал её.
Не знаю. Причина поддержки C++Builder:
1. Это корпоративные пользователи, привыкшие покупать инструментарий.
2. Это было просто. Не потребовалось заново писать плагин. Подробнее: "Как мы разрабатывали версию PVS-Studio для Embarcadero RAD Studio".
1. Это корпоративные пользователи, привыкшие покупать инструментарий.
2. Это было просто. Не потребовалось заново писать плагин. Подробнее: "Как мы разрабатывали версию PVS-Studio для Embarcadero RAD Studio".
Вот открыл их отчёт (стр. 74). То, что Вы привели — это данные за 2011 год. В 2012 MS VS уже 45%, а Eclipse — 16%.
Да, я ошибся, 2011. Но даже эти числа не меняют кардинально ситуацию. Разные среды приходят и уходят, а VS остаётся. В 2009 году, например, Eclipse вообще имел 25%.
Я же не говорил, что надо выбросить VS :) Я просто скорее вижу архитектуру так:
1. Не GUI утилита для проверки кода. Так понимаю, что это уже есть.
2. Библиотека с открытым API для получения списка ошибок и т.п.
3. Плагин-обёртка для п.2 для VS/C++Builder и др.
Т.е. даже если оригинально не будет предоставляться плагина для других сред, то открытый API позволит другим дописать и интегрировать в свой любимый инструмент (Qt Creator для меня, например). Или даже создание отдельного инструмента не привязанного к какой-либо IDE.
Понятно, что я оцениваю не понимая внутренностей работы, и возможно всё не так просто.
1. Не GUI утилита для проверки кода. Так понимаю, что это уже есть.
2. Библиотека с открытым API для получения списка ошибок и т.п.
3. Плагин-обёртка для п.2 для VS/C++Builder и др.
Т.е. даже если оригинально не будет предоставляться плагина для других сред, то открытый API позволит другим дописать и интегрировать в свой любимый инструмент (Qt Creator для меня, например). Или даже создание отдельного инструмента не привязанного к какой-либо IDE.
Понятно, что я оцениваю не понимая внутренностей работы, и возможно всё не так просто.
На уровне идеи красиво. На практике, это никто не будет делать.
Представьте, приходит к начальнику сотрудник. И говорит, а давайте купим PVS-Studio за NNNN евро. Но только к нему нету плагина для нашей любимой среды разработки. Я и мой коллега разработаем его, поэтому на пол годика отвлечемся от основного проекта. Вот подпишите. Вопрос, как быстро и далеко сотрудник будет отравлен? :)
Это бы возможно сработало, начни мы раздавать продукт этим энтузиастам бесплатно. Но какая нам от этого польза? Никакой. Зато будет больше работы. (Только не надо говорить, что это повысит узнаваемость бренда и дела у вас как попрут вдруг :).
Представьте, приходит к начальнику сотрудник. И говорит, а давайте купим PVS-Studio за NNNN евро. Но только к нему нету плагина для нашей любимой среды разработки. Я и мой коллега разработаем его, поэтому на пол годика отвлечемся от основного проекта. Вот подпишите. Вопрос, как быстро и далеко сотрудник будет отравлен? :)
Это бы возможно сработало, начни мы раздавать продукт этим энтузиастам бесплатно. Но какая нам от этого польза? Никакой. Зато будет больше работы. (Только не надо говорить, что это повысит узнаваемость бренда и дела у вас как попрут вдруг :).
Отвечу Вам как разработчик плагина: всё ещё проще ) Вы уже сейчас можете интегрировать анализатор в любую IDE, никакой библиотеки с открытым API для этого не нужно.
Сам анализатор — command line утилита, очень похожая по работе на компилятор, интегрировать её в любую IDE не сложнее интеграции компилятора, даже проще, т. к. от файлов требуется только компилябильность, без линковки. И не важно, через плагин это делать или напрямую через сборочную систему (make например).
Для запуска анализатора нужно передать ему параметры компиляции самого файла, плюс несколько дополнительных настроек. На выходе — plain text лог в stdout, одна строка — одно сообщение, всё предельно просто и понятно.
Причём всё это можно вполне сделать и в нашей триал-версии даже, только лог получится без полных путей до файлов и с ним работать над поиском ошибок нельзя будет.
И главное, всё это давно описано в документации на нашем сайте. Но за несколько лет, что она там лежит, никто почему-то так и не изъявил желания сделать плагин под свою любимую IDE )
Сам анализатор — command line утилита, очень похожая по работе на компилятор, интегрировать её в любую IDE не сложнее интеграции компилятора, даже проще, т. к. от файлов требуется только компилябильность, без линковки. И не важно, через плагин это делать или напрямую через сборочную систему (make например).
Для запуска анализатора нужно передать ему параметры компиляции самого файла, плюс несколько дополнительных настроек. На выходе — plain text лог в stdout, одна строка — одно сообщение, всё предельно просто и понятно.
Причём всё это можно вполне сделать и в нашей триал-версии даже, только лог получится без полных путей до файлов и с ним работать над поиском ошибок нельзя будет.
И главное, всё это давно описано в документации на нашем сайте. Но за несколько лет, что она там лежит, никто почему-то так и не изъявил желания сделать плагин под свою любимую IDE )
Интересно было бы сравнить бесплатные статические анализаторы (cppcheck, codan) и PVS-studio. Хотя как codan давится шаблонами я уже насмотрелся :)
Сравнение Cppcheck и PVS-Studio. И с тех пор, мы стали ещё намного лучше. :)
О, спасибо.
Обновлённое сравнение: Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio.
На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
Да. Поддержали: PVS-Studio для Linux.
А почему единорог на логотипе блюет? Его воротит от ошибок?
Ваш инструмент работает только с парой узкораспространенных IDE и их диалектами языка?
А как насчет нормального С++, соответствующего Стандарту? Как насчет самых популярных компиляторов — GCC и Clang? Есть ли интеграция в CMake/QMake?
А как насчет нормального С++, соответствующего Стандарту? Как насчет самых популярных компиляторов — GCC и Clang? Есть ли интеграция в CMake/QMake?
А есть планы по созданию подобного инструмента для C#?
И снова здравствуйте, Андрей! Честно, я ждал когда вы вернетесь на Хабр. Жаль, что это заняло целый год.
Удачных постов!
Удачных постов!
Интересно, а ошибки в TOR и OpenSSL уже исправили? А в других opensource проектах?
Наймите профессионала для перевода сообщений вашей программы. Русский английский ужасен.
Sign up to leave a comment.
Единорог вновь готов к общению с Си++ программистами