Что касается C++ то, я заявляю, что PVS-Studio лучше многих анализаторов кода (ReSharper, Cppcheck, ...). Наступаем на пятки и в ближайшее время превзойдём по многим направлениям Coverity и Klocwork. Я знаю, что PVS-Studio крут и мы регулярно это показываем на практике. Если кто-то хочет опровергнуть, пусть попробует доказать обратное.
Не стоит смешивать статические анализаторы кода и productivity tools. Статический анализ это подробная документация по всем диагностикам, поддержка и консультирование, это интеграция с IncrediBuild, это Standalone, это инструменты интеграции в большой проект (например, база разметки сообщений), отслеживание запусков компилятора (CLMonitoring), рассылка писем и т.д.
А кто те многие, которые выступают против статического анализа?
Я видел их в комментария, в почте. Но я никогда не собирал ссылки на такие дискуссии, поэтому не могу сейчас достать список «100 примеров». В общем с пруфами затруднение и даже как поискать не знаю. С ходу только вспомнилась заметка "Народ против PVS-Studio: дубль первый" с выводом в конце: не следует полагаться на анализаторы, скорее нужно просто повысить свой уровень профессионализма. Формально вывод правильный, но при разборе статьи выясняется, что автор просто не разобрался в вопросе.
Вряд ли взлетит. Все-таки стат анализ нужен не разово, а постоянно.
Мы думаем, такие проверки могут быть хорошим способом познакомиться и продемонстрировать возможности PVS-Studio. А даже если дальнейшее сотрудничество не сложится, в программе станет меньше багов, что тоже хорошо.
Не вижу смысла вдаваться в споры. Вы столь критически настроены, что всё равно не хотите воспринимать, что компиляторы весьма слабо анализируют код, выдавая при этом слишком много ложных срабатываний. И именно поэтому всякими -Wall -Wextra мало кто пользуется. Неудобно!
Если бы это было не так, не было этой базы с 11000 ошибками.
И именно поэтому статические анализаторы такие как PVS-Studio или Coverity были, есть и будут. Они всегда идут на шаг или два впереди компиляторов в плане диагностик.
Увлекаясь критикой стат. анализторов, Вы начинаете приписывать компиляторам магические возможности, которых нет. Например, так дело обстоит с целочисленным переполнением. Эта и подобные ошибки положили начало созданию Viva64, который со временем превратился в PVS-Studio. И искать подобные ошибки компиляторы не умели, не умеют и не собираются учиться. Что-бы не быть голословным, буквально на днях у нас появился новый клиент, купивший лицензию на PVS-Studio ради 64-битных диагностик. Именно ради них! Видимо пришло делать 64-битнео приложение, а оно не работает… :)
Это исключительно Ваше мнение, основанное на желании убедить себя и других, что статический анализ не нужен. У меня другое мнение, основанное на опыте и желании продать анализатор :). Спор бесперспективен.
Такого расчета нет и не будет в силу его сложности. Слишком много факторов и субъективных мнений которые невозможно учесть. Сейчас я приведу аналогию.
Перед вами стоит задача купить 10 компьютеров для нового отдела программистов. Вы не будете делать никакой расчет по оценки окупаемости. Вот как оценить нужно купить мышку за 300 или 400 рублей? Первая дешевле, но вторая надежнее. Как выбрать? Проводить опрос у программистов, читать обзоры? А монитор — 22 или 25 дюймов? Что лучше? Первый дешевле, а второй показывает больше кода и программисты возможно будут работать быстрее. Как посчитать окупаемость для монитора? А стоит экономить на памяти или нет? А наушники нужны для большего комфорта или обойдутся без них?
В итоге вы будете действовать на глазок. Вы просто понимаете, нужен компьютер вот с такой конфигурацией или нет. А от меня хотят услышать такой же сложный расчёт для анализатора. Ведь в нем как и с компьютером много субъективного. Кто может посчитать на сколько процентов увеличивают эффективность работы мониторы разного размера?
Так как же тогда выбирают компьютеры для команды программистов? По ощущению. Вот тоже самое получается и со статическим анализом. Он или нужен или нет. Или чувствуется потребность или нет. Ибо что с компьютерами, что со статическим анализатором траты на зарплаты не соизмеримо больше.
Вы сильно преувеличиваете. К сожалению, подтвердить свои слова я не могу. Для этого нужен проект, который разрабатывался с ключём -w0 (т.е. без предупреждений). Тогда бы можно было запустить компилятор и анализатор и сравнить результаты. Я предполагаю, что анализатор найдет как минимум в 2-3 раза больше, чем компилятор. Однако, тут никаких пруфов нет: только Ваше мнение против моего.
Где все эти программисты? Возможно, я предвзят, но у меня сложилось впечатление, что это определенно попытка популяризации какого-то странного мифа про программистов.
К сожалению, их много. Если у вас есть пара недель свободного времени предлагаю прочитать все комментарии, ко всем нашим статьям в блоге. Вы увидите, что я пишу это от того, что «наболело».
Купи анализатор, докажи что ты круче программиста, поставь засранца на место»
Кстати, в этом что-то есть. Я не призываю так поступать, однако иногда умелое использование такой методики пожалуй может дать воспитательный эффект. :)
Так он уже есть как часть Visual Studio. Т.е. в Visual Studio уже есть встроенный статический анализтор. Только пользоватся на практике им нельзя. Мало толковых предупреждений и очень много не по делу.
Что касается C++ то, я заявляю, что PVS-Studio лучше многих анализаторов кода (ReSharper, Cppcheck, ...). Наступаем на пятки и в ближайшее время превзойдём по многим направлениям Coverity и Klocwork. Я знаю, что PVS-Studio крут и мы регулярно это показываем на практике. Если кто-то хочет опровергнуть, пусть попробует доказать обратное.
Да и вообще, никто не обещал, что переполнение будет знаковым.
Ну-ну… Попробуйте искать так ошибки в большом проекте. Да и вообще, никто не обещал, что переполнение будет целочисленным. Я же написал:
Если бы это было не так, не было этой базы с 11000 ошибками.
И именно поэтому статические анализаторы такие как PVS-Studio или Coverity были, есть и будут. Они всегда идут на шаг или два впереди компиляторов в плане диагностик.
Увлекаясь критикой стат. анализторов, Вы начинаете приписывать компиляторам магические возможности, которых нет. Например, так дело обстоит с целочисленным переполнением. Эта и подобные ошибки положили начало созданию Viva64, который со временем превратился в PVS-Studio. И искать подобные ошибки компиляторы не умели, не умеют и не собираются учиться. Что-бы не быть голословным, буквально на днях у нас появился новый клиент, купивший лицензию на PVS-Studio ради 64-битных диагностик. Именно ради них! Видимо пришло делать 64-битнео приложение, а оно не работает… :)
Перед вами стоит задача купить 10 компьютеров для нового отдела программистов. Вы не будете делать никакой расчет по оценки окупаемости. Вот как оценить нужно купить мышку за 300 или 400 рублей? Первая дешевле, но вторая надежнее. Как выбрать? Проводить опрос у программистов, читать обзоры? А монитор — 22 или 25 дюймов? Что лучше? Первый дешевле, а второй показывает больше кода и программисты возможно будут работать быстрее. Как посчитать окупаемость для монитора? А стоит экономить на памяти или нет? А наушники нужны для большего комфорта или обойдутся без них?
В итоге вы будете действовать на глазок. Вы просто понимаете, нужен компьютер вот с такой конфигурацией или нет. А от меня хотят услышать такой же сложный расчёт для анализатора. Ведь в нем как и с компьютером много субъективного. Кто может посчитать на сколько процентов увеличивают эффективность работы мониторы разного размера?
Так как же тогда выбирают компьютеры для команды программистов? По ощущению. Вот тоже самое получается и со статическим анализом. Он или нужен или нет. Или чувствуется потребность или нет. Ибо что с компьютерами, что со статическим анализатором траты на зарплаты не соизмеримо больше.
Кстати, в этом что-то есть. Я не призываю так поступать, однако иногда умелое использование такой методики пожалуй может дать воспитательный эффект. :)
- Сравнение анализаторов кода: CppCat, Cppcheck, PVS-Studio, Visual Studio
- Как мы сравнивали анализаторы кода CppCat, Cppcheck, PVS-Studio, Visual Studio
Сейчас отрыв будет ещё больше.