Comments 82
99% это MFC/ATL код — мы все знаем как он писался и когда… честно говоря, открывая данную статью надеялся увидеть ошибки в стандартной библиотеке, что гораздо интереснее. Да и используется стд в наше время всё больше и больше нежели умирающие древности типа MFC/ATL.
Поддерживаю. Открывал статью в надежде посмотреть как анализатор справится с развестисым спагетти шаблонов в std-библиотеке.
В шаблонах особенно анализировать нечего. В том смысле, там куда не пойди везде неизвестные типы. В связи с этим анализ крайне ограничен в возможностях, потому что, когда нельзя вывести тип, лучше молчать.
Поясню на примере. Выход за границу массива:
Анализатор PVS-Studio здесь молчит. Ибо не понятно, что такое это T, какой тип массива и какой тип у индекса 'i'.
Но стоит добавить ниже:
И анализатор PVS-Studio радостно выдаст предупреждение:
Так что не стоит ожидать от анализатора чудес, если просто напихать в проект заголовочных файлов с шаблонными классами и функциями (что собственно я и сделал).
Поясню на примере. Выход за границу массива:
template <class T> class Foo
{
void F()
{
T a[10];
for (T i = 0; i != 11; ++i)
a[i] = i;
}
};
Анализатор PVS-Studio здесь молчит. Ибо не понятно, что такое это T, какой тип массива и какой тип у индекса 'i'.
Но стоит добавить ниже:
void Q()
{
Foo<int> x;
}
И анализатор PVS-Studio радостно выдаст предупреждение:
V557 Instantiate Foo <int>: Array overrun is possible. The value of 'i' index could reach 10. Level: 2
Так что не стоит ожидать от анализатора чудес, если просто напихать в проект заголовочных файлов с шаблонными классами и функциями (что собственно я и сделал).
Дык и не надо ожидать — нужно просто взять более или менее сложный реальный проект(для чистоты эксперимента) с большим обилием стд и проверить его вместе со стандартной библиотекой, ну или на худой конец написать тесты хотя бы со стандартными типами — это не долго, хотя бы ради статьи. Все мы крестовики — и я не говорю про синтетические ситуации — типа перекрытого оператора неравенства != 11. Таких ситуации, которые выстреливают мимо бага одна на миллион. И на 90% этот анализ отразит состояние стандартной библиотеки того или иного компилятора — тем более Ваш PVS анализатор не плохо с этим справляется. А глазками уже можно будет понять баг это или фича или какая-то уникальная ситуация — и если это баг, отразить в статье — вот так как-то…
ПС
Вы создали великолепный продукт, но не нужно надеяться на то, что он за Вас будет и статьи на хабре писать, если Вы заявляете про анализ «Visual C++ 2017 Libraries» нужно ожидать, что люди ждут анализа именно самой главной — т.е. стандартной библиотеки — а что Вы хотели…
ПС
Вы создали великолепный продукт, но не нужно надеяться на то, что он за Вас будет и статьи на хабре писать, если Вы заявляете про анализ «Visual C++ 2017 Libraries» нужно ожидать, что люди ждут анализа именно самой главной — т.е. стандартной библиотеки — а что Вы хотели…
Лучше бы исходники симбиан проверили. Хотя бы библиотеку User(содержит реализацию много чего разного, используется — везде)
Я в очередной раз смог продемонстрировать читателю, какую пользу могут приносить инструменты статического анализа кода.
Увы, вы очередной раз доказали, что
А надо доказать не только то, что цена оправдывается, а что покупка PVS-Studio выгодней иных методов повышения качества кода.
Ну и последнее. Ваш ест показывает ошибку (мисфичу) в PVS-Studio, которой вы просто не заметили. Не так уж и редко бывают ситуации, когда один и тот же код должен компилироваться компиляторами, использующими разные версии стандарта. При этом основная масса кода использует старый стандарт, а в отдельных местах условной компиляцией вводятся альтернативные куски для старого и нового стандарта.
Судя по вашим примерам — тут ровно такая же ситуация. Но… судя по вашей статье PVS-Studio просто не позволяет и принимать фичи новых стандартов и считать правильным то, что должно было быть по старым стандартам.
Надо ли исправлять эту мисфичу — не знаю, это вопрос маркетинга. Но факт, что вы её не заметили.
Это неправильный подход. Ценность статического анализа не в разовом запуске, а в его регулярном использовании. При регулярных запусках многие ошибки можно устранять на самых ранних этапах, а не когда о них сообщают пользователи. Например, вот человек в ответ на мой твит пишет:
I reported similar bug in MFC, they have leaked some tooltips or whatnot in function CMFCToolBar::UpdateTooltips. I found it by umdh tool.
И зачем так сложно, когда такую ошибку можно было бы найти самим разработчикам библиотек сразу после написания кода?
Отсюда следует, что фраза «не вижу, что найденные вами ошибки оправдывают те килобаксы, которые стоит PVS-Studio», логически неверная. Проведу аналогию с предупреждениями компилятора. Представим, что есть работающий проект, который разрабатывается с отключенными предупреждениями компилятора. Включаем их и смотрим. Есть ли смысл тратить и дальше время на их изучение, или лучше опять их выключить? Вряд ли предупреждения укажут на серьезную ошибку, проект ведь отлажен и работает. По предложенной Вами логике предупреждения надо отключить, так как они не показали свою ценность, не найдя фатальные ошибки.
I reported similar bug in MFC, they have leaked some tooltips or whatnot in function CMFCToolBar::UpdateTooltips. I found it by umdh tool.
И зачем так сложно, когда такую ошибку можно было бы найти самим разработчикам библиотек сразу после написания кода?
Отсюда следует, что фраза «не вижу, что найденные вами ошибки оправдывают те килобаксы, которые стоит PVS-Studio», логически неверная. Проведу аналогию с предупреждениями компилятора. Представим, что есть работающий проект, который разрабатывается с отключенными предупреждениями компилятора. Включаем их и смотрим. Есть ли смысл тратить и дальше время на их изучение, или лучше опять их выключить? Вряд ли предупреждения укажут на серьезную ошибку, проект ведь отлажен и работает. По предложенной Вами логике предупреждения надо отключить, так как они не показали свою ценность, не найдя фатальные ошибки.
Вы что хотите? Чтобы взломали защиту и использовали PVS-Studio бесплатно? Или все-таки продавать?
Включение предупреждений компилятора — бесплатно (даже если сам компилятор платный). К расходам относится только время, потраченное на разбор предупреждений.
А PVS-Studio — это куча килобаксов. Вот и докажите экономическим расчетом, что эти килобаксы оправдываются. И не просто оправдываются, а ещё и эффективней иных методов.
Помножьте найденные вами ошибки на 10 или 100. Разве они оправдывают цену PVS-Studio? В обычной ситуации коммерческого кода — не оправдывают.
Вы бы для сравнения тот же код под gcc с -Wall -Wextra откомпилировали. Или под clang. Были бы хоть данные, насколько больше (или меньше) ошибок находит PVS-Studio.
А я именно этот эксперимент сделал и описал. Включаем предупреждения — ничего. CppCheck — ерунда, жаль времени на анализ. Переводим под linux/gcc с -Wall -Wextra — и имеем вагон полезных замечаний. Вывод — даже бесплатный CppCheck не оправдывается. А вы предлагаете потратить килобаксы.
Так все-таки, вы хотите, чтобы PVS-Studio пиратили или покупали?
Включение предупреждений компилятора — бесплатно (даже если сам компилятор платный). К расходам относится только время, потраченное на разбор предупреждений.
А PVS-Studio — это куча килобаксов. Вот и докажите экономическим расчетом, что эти килобаксы оправдываются. И не просто оправдываются, а ещё и эффективней иных методов.
Помножьте найденные вами ошибки на 10 или 100. Разве они оправдывают цену PVS-Studio? В обычной ситуации коммерческого кода — не оправдывают.
Вы бы для сравнения тот же код под gcc с -Wall -Wextra откомпилировали. Или под clang. Были бы хоть данные, насколько больше (или меньше) ошибок находит PVS-Studio.
Представим, что есть работающий проект, который разрабатывается с отключенными предупреждениями компилятора. Включаем их и смотрим. Есть ли смысл тратить и дальше время на их изучение, или лучше опять их выключить?
А я именно этот эксперимент сделал и описал. Включаем предупреждения — ничего. CppCheck — ерунда, жаль времени на анализ. Переводим под linux/gcc с -Wall -Wextra — и имеем вагон полезных замечаний. Вывод — даже бесплатный CppCheck не оправдывается. А вы предлагаете потратить килобаксы.
Так все-таки, вы хотите, чтобы PVS-Studio пиратили или покупали?
PVS не продаст свой анализатор тем, кто захочет его спиратить.
Причем что-либо ломать тоже не нужно.
Нужно:
1) Проставить во всех файлах комментарии "this file is checked with pvs-..."
2) Запустить pvs studio
3) удалить комментарии
Причем это придумали в тот момент, когда появилась бесплатная версия лицензии на PVS.
Разработчики вроде говорили, что пираты им в любом случае не заплатили бы.
Проще скачать демо-версию под linux и использовать её. Только это все равно будет пиратское использование, ибо демо-версия предназначена лишь для оценки перед покупкой. По хорошему, найденные ей ошибки в коде исправлять до покупки анализатора нельзя, ибо тогда это уже будет использование, а не оценка.
А пиратить программы российских коллег — ну как-то западло. Была бы западная — использовал бы и не парился. А российское — ну вот не привык я так. Слишком уж тесен этот мир.
Note that this mode is not intended to evaluate this software. Please use a demo version or request a temporary license key to try out the analyzer.
А пиратить программы российских коллег — ну как-то западло. Была бы западная — использовал бы и не парился. А российское — ну вот не привык я так. Слишком уж тесен этот мир.
Нужно: 1) проставить во всех файлах комментарии "this file is checked with pvs-..."; 2) запустить pvs studio; 3) удалить комментарии.
Этот сценарий использования является пиратством, так как явно запрещён лицензией (секция «Update»). Правильней всего просто не использовать этот анализатор (и, тем более, не делать ему рекламы) если не согласны с лицензией.
UFO just landed and posted this here
Есть бесплатная версия для разработчиков открытого кода.
А между прочим вполне правильный вопрос поднят.
Вопрос поднят неправильно, почему:
Условно говоря у каждой ошибки есть цена...
Что Jef239, и теперь Вы, говорите о какой-то «условной» величине, которую никто даже не потрудился назвать, а почему? Потому что её нет, это «внутренная кухня» компаний, в которых эксперты уже подсчитали все риски, приняли решение о преобретении инструмента или об отказе от него. И как вы уже поняли, перед нами никто не должен отчитываться в этом.
Это расходится с вашими поисками ошибок в открытом коде.
Давно не секрет, что на открытых проектах мы демонстрируем возможти анализатора, всегда уведомляя авторов. Давно есть возможность использовать PVS-Studio бесплатно.
поправьте пожалуйста если я ошибаюсь
Поправил.
Давно есть возможность использовать PVS-Studio бесплатно.
Недавно думал посоветовать одному из своих студентов прикрутить PVS-Studio к дипломному проекту. Посмотрел на формулировку вида «Dear PVS-Studio, would you kindly check my stupid project, please.» и передумал советовать. Формально вы правы: вы даёте возможность пользоваться своим продуктом бесплатно, но «вы делаете это без уважения».
В особенности я не согласен с вашей политикой размещать этот комментарий именно на первых двух строках файла с кодом: если каждый условно-бесплатный инструмент начнёт требовать подношений таким образом, то больше одного такого инструмента подключить к проекту не получится.
Впрочем, вы, наверняка, все подобные аргументы уже слышали. Уверен, вы сознательно выбрали именно такие формулировки и ограничения, и это целиком ваше право. Право недовольных — предпочесть ваших конкурентов, несмотря на тот информационный шум, что вы устраиваете на Хабре.
Недавно думал посоветовать одному из своих студентов прикрутить PVS-Studio к дипломному проекту.
Лучше посоветуйте. Сам писал для диссертации большое приложение с MPI и в последние дни, когда делал срочные правки, смог поймать ошибки с индексами.
Насчёт комментариев всё просто. Большинству людей всё равно до парочки комментариев, особенно студентам. Это защита от коммерческих проектов с открытым исходным кодом.
Это защита от коммерческих проектов с открытым исходным кодом.
И с закрытым тоже. :) Не каждый менеджер будет рад видеть в проекте компании такие комментарии.
Лучше посоветуйте.
Лично я нахожу условия неприемлемыми для любого публикуемого проекта, независимо от его лицензии. Как с таким убеждением можно кому-то рекомендовать принять эти условия?
(...) когда делал срочные правки, смог поймать ошибки с индексами.
У нас возможностей запутаться в индексах просто море, но мы возлагаем большие надежды на ассерты и valgrind.
Не каждый менеджер будет рад видеть в проекте компании такие комментарии.
Я не менеджер, но совершенно не рад видеть строчки с сюрным текстом первыми в файле. При этом, я бы вполне смирился с упоминание об анализаторе (со ссылкой на сайт разработчика), но в более нейтральной формулировке и сразу после информации о лицензии проекта.
Не могу представить подобного рода комментарии, например, в Boost или Qt. Выдвигая такие условия, вы достаточно ясно говорите своей аудитории: «На самом деле, мы не хотим, чтобы вы использовали наш анализатор бесплатно для чего-то серьёзного — поэтому или идите купите лицензию, или превратите свой проект в нашу рекламную вывеску.»
Выдвигая такие условия, вы достаточно ясно говорите своей аудитории: «На самом деле, мы не хотим, чтобы вы использовали наш анализатор бесплатно для чего-то серьёзного — поэтому или идите купите лицензию, или превратите свой проект в нашу рекламную вывеску.»
Да, так и задумано. Не вижу ничего в этом плохого или нечестного.
У нас возможностей запутаться в индексах просто море, но мы возлагаем большие надежды на ассерты и valgrind.
Возлагать то можно, но лучше, когда разные инструменты дополняют друг друга. Тот-же valgrind не видит то, что замечает PVS-Studio. Ну-ка, что это у него такое вот тут в коде:
} else {
goto no_match; //ATC
cc = iselCondCode( env, guard );
}
Ай, это же мёртвый код. Фи, нехорошо… :) В пятницу будет статья про проверку valgrind.
«… или идите купите лицензию, или превратите свой проект в нашу рекламную вывеску.»
Да, так и задумано. Не вижу ничего в этом плохого или нечестного.
Я тоже не вижу ничего нечестного. Но анализатор ваш не порекомендую использовать никому и никогда.
Ай, это же мёртвый код. Фи, нехорошо.
Для этого совершенно не обязательно использовать PVS-Studio. Опция -Wunreachable-code, вовремя переданная в clang++ (жаль, что из GCC её молча выпилили), позволит разработчику сэкономить немного денег/самоуважения.
Для этого совершенно не обязательно использовать PVS-StudioЭто всё лирика. :) Обязательно, не обязательно, а ошибка найдена именно с помощью PVS-Studio. Как и ещё 11037 ошибок. О чем это говорит?
- Анализатором PVS-Studio для поиска многих ошибок пользоваться удобнее и приятнее, чем компиляторами. У компиляторов много ложных срабатываний, неудобный способ фильтрации, плохая документация и т.д.
- Анализатор PVS-Studio мощнее. Более того, процесс работы над ядром анализатора только усиливается.
И за это мы получаем деньги.
И ещё мы очень скромные, да.
Формально вы правы: вы даёте возможность пользоваться своим продуктом бесплатно, но «вы делаете это без уважения».Ещё один новый вариант: Бесплатный PVS-Studio для тех, кто развивает открытые проекты. Не знаю, получилось в этот раз с уваженеим или нет… :)
UFO just landed and posted this here
Вопрос — что дешевле, купить PVS или на эти деньги нанять пару лишних тестировщиков
Цена анализатора по сравнению стоимостью зарплаты команды программистов пренебрежимо мала. Так что не понятно, что тут собственно высчитывать. Анализ кода (т.е. контроль его качества) или нужен, или не нужен.
Я даже про тестировщиков не понимаю. Возьмём двух тестировщиков с зарплатой скажем в 40000р. В год на них будет потрачено 40*2*12=960 т.р. Это ещё без налогов. А если добавить траты на рабочие места, аренду, бух. сопровождение и т.д., то в итоге эти два тестировщика за год съедят около 1,5 млн. рублей. Эти траты уже в несколько раз больше, чем стоимость базовой версии PVS-Studio.
Поэтому я и говорю, Вам или нужен дополнительный контроль качества кода или не нужен. Статический анализ, это ответ на вопрос «что мы ещё можем сделать для улучшения качества проекта?». Естественно на него стоит отвечать только тогда, когда уже есть и квалифицированные программисты и тестировщики. А если их нет, тут уж не до статического анализа… :)
P.S. Не нравится в своём собственном ответе, что я о статическом анализе сказал как только о приятном дополнении в виде повышения качества кода. Но ведь очень важно, что выявление ошибок на ранних этапах, это ещё и большая экономия времени на отладку и тестирование. Т.е. ошибка может быть найдена сразу и исправлена. А если её будет находить дополнительно нанятый человек, то это целый процесс, где будет участвовать тестировщик, программист, багтрекер, отладчик и так далее. К сожалению, тут посчитать вообще очень сложно.
Статический анализ, это ответ на вопрос «что мы ещё можем сделать для улучшения качества проекта?».
Вот именно. На сей раз вы правы на 100%. В этой ситуации можно ракеты освящать. Или офисы сбербанка. Можно рядом с каждым монитором персональный кактус поставить. А можно и станализатор прикупить. Особенно, если проект в стадии агонии, то есть каждое изменение в коде может давать неожиданные эффекты, которые никто не может предвидеть.
А обычно вопрос иной: а во что нам выгоднее вложить средства? В рекламу? В маркетинг? В поиск новых ниш на рынке? В развитие продукта? Или в улучшение качества? Что даст больший доход?
А если уж вкладывать в улучшение качества, то какие меры будут эффективней? Выдать каждлму разработчику по бубну? Ввести систему премий и штрафов? Сделать рефакторинг? Переписать продукт с нуля? Применить одну из модных технологий?
А какую модную технологию применить? TDD? Парное программирование? Купить станализатор?
И вот тут от вас ждут ответа почему покупка статанализатора выгодней, чем реклама. А ответа у вас, увы нет.
И вот тут от вас ждут ответа почему покупка статанализатора выгодней, чем реклама. А ответа у вас, увы нет.
Вы опять что-то попутали. Мы утверждаем, что исправлять ошибки в коде сразу выгоднее, чем тащить их через тестеров и клиентов. Выгоднее, чем зарплата нескольких тестеровщиков…
Какая реклама, вы чего? Мы не участвуем в планировании действий компаний, не ходим на их собрания и не планируем их бюджет… Что за бред?
Вот только ваша компания не покупает Coverity, хотя качество кода он нам несомненно улучшит. Немного, на доли процента — но ведь улучшит?
Зато — вы активно рекламируете свой продукт. Настолько активно, что по словами «Статический анализ» находятся в основном статьи вашей компании.
Как видите, вашей компании реклама намного важнее качества кода. И это нормальная ситуация. Обычно важнее всего рынок сбыта, потом развитие продукта (для удержания и захвата рынка сбыта) и где-то близко к последнему месту — качество кода.
И лишь в двух ситуациях качество кода становится существенным:
Докажите это. Только нормальными расчетами экономики. И без сказок о том, PVS-studio находит ошибки на уровне тестера.
Собственно именно этого доказательства мы от вас и ждем.
Зато — вы активно рекламируете свой продукт. Настолько активно, что по словами «Статический анализ» находятся в основном статьи вашей компании.
Как видите, вашей компании реклама намного важнее качества кода. И это нормальная ситуация. Обычно важнее всего рынок сбыта, потом развитие продукта (для удержания и захвата рынка сбыта) и где-то близко к последнему месту — качество кода.
И лишь в двух ситуациях качество кода становится существенным:
- Когда оно настолько низко, что продукт вошел в стадию агонии, то есть «каждое изменение в коде может давать неожиданные эффекты, которые никто не может предвидеть.»
- Когда у нас специфичная область (авионика, атомная энергетика и так далее).
Мы утверждаем, что исправлять ошибки в коде сразу выгоднее, чем тащить их через тестеров и клиентов. Выгоднее, чем зарплата нескольких тестеровщиков…
Докажите это. Только нормальными расчетами экономики. И без сказок о том, PVS-studio находит ошибки на уровне тестера.
Собственно именно этого доказательства мы от вас и ждем.
Докажите это. Только нормальными расчетами экономики.
У разработчика Вовы был хороший день, пока начальник не сообщил, что у клиентов, которые обновили софт на всех офисных компьютерах — появились проблемы с вводом данных.
Вова потратил несколько часов, изучая разные ревизии кода и нашёл следующую ошибку:
void SetActive(bool bActive)
{
if (bActive == bActive)
return;
m_bActive = bActive;
OnResetState();
}Некий контрол для ввода в некоторых ситуациях не становился активным.
Вопрос: сколько люлей получил Вова и его руководство за простой в бизнесе клиентов? Сколько можно было бы сэкономить, найдя ошибку статическим анализатором?
В ответ на вашу вымышленную историю — реальная ситуация. В авионике станализаторы используются в обязательном порядке. Причем очень высокого класса. И что? Помогли они хоть капельку? Дичайший баг: в релизе просто не реализован алгоритм из ТЗ, а станализатор молчок.
А в вашей истории про Вову — как раз был смысл нанять тестера. Потому что если бы было написано if (bActive == bActive1) — стат анализатор бы ничего не заподозрил. А если бы тестер был — люлей дали бы ему, а не девелоперу. Ну или на gcc перейти — у него есть эта диагностика.
P.S. Частный пример того, что находят компиляторы — это не доказательство. Увы, это обычный маркетинговый обман.
А в вашей истории про Вову — как раз был смысл нанять тестера. Потому что если бы было написано if (bActive == bActive1) — стат анализатор бы ничего не заподозрил. А если бы тестер был — люлей дали бы ему, а не девелоперу. Ну или на gcc перейти — у него есть эта диагностика.
P.S. Частный пример того, что находят компиляторы — это не доказательство. Увы, это обычный маркетинговый обман.
Дичайший баг: в релизе просто не реализован алгоритм из ТЗ, а станализатор молчок.
Если по утрам пользоваться статическим анализатором PVS-Studio, то можно своевременно узнать о простуде и принять меры. Но об этом тссс… Контр-фича войдёт только в следующий релиз. Тссс…
Зато бубен давно помогает находить очень много.
И не только находить. Только плясками с бубном вы заставите неработающий код — работать.
И не только находить. Только плясками с бубном вы заставите неработающий код — работать.
Скажите а PVS-Studio делает:
Нахождение тех кодовых ошибок, что может найти статанализатор — это 5% времени тестера, не более.
Ну вот и считаем. 5% от 1.5 миллиона — это 75 тысяч. В 4.5 раз меньше цены PVS-Studio
А теперь вспомним, что тестер находит баги, которые вылезут у большинства клиентов, а статанализатор — и то, что вылезет и то, что практически никогда не вылезет…
И в итоге получается совсем печальная для вас картина.
У меня есть предложение. Вы можете снабдить демо-версию нормальной лицензией? Интересуют два момента:
Взамен можно проверять присутствие в файле (на любой строке) комментария «Checked by DEMO-version of PVS-Studio». И добавлять его, если такого комментария не нашлось.
Вполне возможно, что как раз DEMO-версия — продаваема. По бросовым ценам, но продаваема. В смысле консольная версия, которая не имеет «кликов», и связанных с ними ограничений.
- нагрузочное тестирование, то есть нахождение бутылочных горлышек в архитектуре?
- проверку соответствие документации коду?
- регрессионное тестирование?
- проверку на полноту реализации ТЗ?
- ищет грамматические ошибки в документации?
- находит неудобства у UI?
- и так далее, и так далеее
Нахождение тех кодовых ошибок, что может найти статанализатор — это 5% времени тестера, не более.
Ну вот и считаем. 5% от 1.5 миллиона — это 75 тысяч. В 4.5 раз меньше цены PVS-Studio
А теперь вспомним, что тестер находит баги, которые вылезут у большинства клиентов, а статанализатор — и то, что вылезет и то, что практически никогда не вылезет…
И в итоге получается совсем печальная для вас картина.
У меня есть предложение. Вы можете снабдить демо-версию нормальной лицензией? Интересуют два момента:
- Разрешение на использование демо-версии без цели покупки
- Разрешение на изменение кода по данным анализа, произведенным демо-версией.
Взамен можно проверять присутствие в файле (на любой строке) комментария «Checked by DEMO-version of PVS-Studio». И добавлять его, если такого комментария не нашлось.
Вполне возможно, что как раз DEMO-версия — продаваема. По бросовым ценам, но продаваема. В смысле консольная версия, которая не имеет «кликов», и связанных с ними ограничений.
Возникает вполне конкретный вопрос — насколько эта польза измерима? Или это, цитирую «условная величина, которую никто даже не потрудился назвать „
Давайте посадим дерево, выпьем минеральной воды, поспим 8 часов… насколько эта польза измерима?
Есть много других способов улучшить качество кода.
Есть много других способов улучшить качество кода. Не пойму, где конфликт. Обычно компании применяют комплексные меры для повышения качества кода. Есть ещё много других способов управления проектом, тоже помогает. Опять, нет конфликта ни программ, ни людей.
А причина минусов простая — PVS-Studio надо рассматривать наравне с бубном, кактусами у мониторов, освящением помещений и кучей других верований и суеверий.
При этом я не отрицаю, что с помощью плясок с бубном было исправлено множество ошибок. И сам могу продемонстрировать пользу бубна. Ибо любое плацебо — немного помогает.
Но секте поклонников PVS-studio ни вы, ни я ничего не докажем. Проще уж вегетарианца научить есть мясо.
При этом я не отрицаю, что с помощью плясок с бубном было исправлено множество ошибок. И сам могу продемонстрировать пользу бубна. Ибо любое плацебо — немного помогает.
Но секте поклонников PVS-studio ни вы, ни я ничего не докажем. Проще уж вегетарианца научить есть мясо.
говорите о какой-то «условной» величине, которую никто даже не потрудился назвать, а почему?
Потому, что не вижу смысла объяснять то, что все проходили в школе на уроках обществоведения. Деньги — это мерило стоимости товара. Так что измеряться они будут в рублях.
Потому что её нет, это «внутренная кухня» компаний, в которых эксперты уже подсчитали все риски, приняли решение о преобретении инструмента или об отказе от него.
Ну вот уже и мифические эксперты появились. Гм, видимо придется объяснить, почему мифические…
«Анализ эффективности внедрения» — это абсолютно обычная вещь для любых систем. Вот вам для CRM, вот для СЭД, вот для ИС, вот для АСУ. Уровень — от курсовой до научной работы. Для некоторых областей — даже ГОСТ есть.
А вот по анализу эффективности внедрения статического анализа не находится ничего релевантного. Так что никакой науки тут нет. Ну и соответственно — нет экспертов. Единственные, кого можно назвать экспертами — это вы и сами и другие разработчики статнализаторов.
Давно не секрет, что на открытых проектах мы демонстрируем возможти анализатора
Вот в этом и ваша проблема, что вы демонстрируете возможности, а не экономическую эффективность. Знаете, у сверхзвукового истребителя тоже вагон возможностей, Но многие ли хотят его купить себе? Покупают-то больше ford focus, у которого и скорость поменьше, и кучи возможностей нет…
Потому что её нет, это «внутренная кухня» компаний,
Да нет, многие рассказывают о своей кухне. Но в одной из статей вы проговорились.
В больших проектах уже никто не знает, как всё работает. Из-за этого поиск и исправление ошибки обходятся на порядок дороже. Каждое изменение в коде может давать неожиданные эффекты, которые никто не может предвидеть.
Эта стадия проекта называется агония, потому что следующая стадия — это смерть. И вот такие агонизирующие проекты — и есть ваши клиенты. Правильное решение — переписать систему заново, с нуля. Но такое решение настолько дорого, что менеджмент хватает за разного рода соломинки. Освящает помещения, зовет шаманов, закупает статический анализатор…
Не удивлюсь, если большинство ваших клиентов — это именно агонизирующие системы. Ничего страшного в этом нет, просто нужно честно признать — PVS-Sdudio — это продукт для систем в стадии агонии.
А для обычных PVS-Studio просто не выгоден. Вот вам простейший экономический расчет на уровне начальной школы. Поскольку современная цена PVS-Studio неизвестна, возьмем цены 2013 года: €5250 на 9 разработчиков на год, то есть примерно 330 труб по курсу. На одного разработчика это будет 36.6 труб на год.
Не секрет, что работодатель на одного работника тратит примерно в полтора раза больше, чем зарплата, выдаваемая на руки. При зарплате в 50 труб в месяц в год будет 50*12*1.5 = 900 тысяч рублей. В году примерно 2 тысячи рабочих часов. Таким образом цена часа 450 рублей.
Получается, что для нулевой окупаемости PVS-Studio должен экономить 33600/450 — примерно 75 часов в год, то есть почти 10 рабочих дней.
Увы, весь ваш блог показывает, что речь идет лишь о копеечной экономии. Да, может быть для разработчика с оплатой 500 труб в месяц PVS-Studio будет выгодной. Но это не массовый сегмент.
Увы, при развитии PVS-studio было допущено много менеджерских ошибок. И ваше нынешнее непонимание экономики — это всего лишь очередная ошибка. Равно как и отсутствии образа типичного покупателя, отсутствие внятной лицензии на демо-версию и так далее…
Среди их клиентов:
- Microsoft
- Epic Games
- Wargaming
- Kaspersky
Неужели вендекапец так близко?
В микрософт — 120 тысяч работников. Ну скажем 50 тысяч программистов. Цена enterprise лицензии от от €9000, ну скажем $50 000. Получается — по доллару на програмиста в год.
ВАУ! «Дайте две!» При годовой стоимости в доллар — я сам куплю с удовольствием. И не буду смотреть, важное или неважное он нашел. Рано или поздно — найдет важное и окупиться. Тут главное, чтобы польза от найденного была больше, чем время на прочтение и анализ диагностик.
Иными словами — экономика фирмы с сотней тысяч работников — совсем другая.
Что касается «венлекапец», то линейка Windows 95/98 начала писаться с 1983 года и скончалась в 2000 с выпуском WinME. Судя по книгам с разбором кода — как раз полная агония там и была. Линейка Windows NT/XP/7/10 начала писаться с 1988ого года. За 19 лет — скорее всего никого из исходной команды не осталось. С другой стороны — там была классная команда архитекторов. Так что думаю, что агональная стадия там лишь местами. И лет 10 ещё винда проживет.
ВАУ! «Дайте две!» При годовой стоимости в доллар — я сам куплю с удовольствием. И не буду смотреть, важное или неважное он нашел. Рано или поздно — найдет важное и окупиться. Тут главное, чтобы польза от найденного была больше, чем время на прочтение и анализ диагностик.
Иными словами — экономика фирмы с сотней тысяч работников — совсем другая.
Что касается «венлекапец», то линейка Windows 95/98 начала писаться с 1983 года и скончалась в 2000 с выпуском WinME. Судя по книгам с разбором кода — как раз полная агония там и была. Линейка Windows NT/XP/7/10 начала писаться с 1988ого года. За 19 лет — скорее всего никого из исходной команды не осталось. С другой стороны — там была классная команда архитекторов. Так что думаю, что агональная стадия там лишь местами. И лет 10 ещё винда проживет.
Они лет 7 пытались убедить разработчиков. Не вышло. Теперь пытаются убедить менеджеров. Тоже вряд ли выйдет. Собственно они уже разок проговорились о своей модели клиента:
Была у них хорошая идея с SaaS. Но моя личная попытка узнать у них цены просто провалилась. В ответ очень веждиво и многословно цену назвать отказались.
В больших проектах уже никто не знает, как всё работает. Из-за этого поиск и исправление ошибки обходятся на порядок дороже. Каждое изменение в коде может давать неожиданные эффекты, которые никто не может предвидеть. Поэтому, если инструмент помогает предотвратить хотя-бы 10% ошибок, это уже огромная экономия сил и в времени.
Была у них хорошая идея с SaaS. Но моя личная попытка узнать у них цены просто провалилась. В ответ очень веждиво и многословно цену назвать отказались.
Они лет 7 пытались убедить разработчиков. Не вышло.
Да ладно? Мне вот польза (подчёркиваю: польза, а не "панацея") статического анализатора очевидна. Аналогично с тестами, ревью, "континюес интегрейшн" и прочими валгриндами. Знакомые программисты мнение разделяют.
Другое дело, что решение как расходовать деньги, зачастую, принимают как раз не программисты, а менеджеры.
Тогда, может быть, поделитесь своими знаниями? Беда в том, что кроме пользы, есть стоимость анализа. Она складывается из трех вещей: цена анализатора, время на разбор результатов, время на приведение кода в состояние, когда нет предупреждений.
Когда сотрудники простаивают, а анализатор бесплатен — польза есть от любого анализатора. А вот когда у сотрудников цейтнот, а анализатор стоит килобакс — вместо пользы легко получить проигрыш. Как по деньгам — так и по срокам завершения проекта.
Я уже много раз писал свою оценку. Компиляция с -Wall -Wextra оправдывается. Даже если для этого проект надо переводить с винды на linux. А вот cppcheck не оправдывается. Обычно после проверки им жалко времени, потраченного на анализ. Ну вот вам один из примеров.
Если вы считаете, что польза от PVS-Studio есть, то расскажите, что же оправдывает килобакс его цены? Насколько ускорилась сдача проекта? Насколько увеличились продажи?
Когда сотрудники простаивают, а анализатор бесплатен — польза есть от любого анализатора. А вот когда у сотрудников цейтнот, а анализатор стоит килобакс — вместо пользы легко получить проигрыш. Как по деньгам — так и по срокам завершения проекта.
Я уже много раз писал свою оценку. Компиляция с -Wall -Wextra оправдывается. Даже если для этого проект надо переводить с винды на linux. А вот cppcheck не оправдывается. Обычно после проверки им жалко времени, потраченного на анализ. Ну вот вам один из примеров.
Если вы считаете, что польза от PVS-Studio есть, то расскажите, что же оправдывает килобакс его цены? Насколько ускорилась сдача проекта? Насколько увеличились продажи?
Компиляция с -Wall -Wextra оправдывается. Даже если для этого проект надо переводить с винды на linux.
Не хочу никого обидеть, но такую оценку может дать только неопытный человек. Анализ | портирование — эти задачи даже рядом не стоят по требуемым затратам.
У нас основной проект работает под MS-DOS, Windows, freeBSD, QNX, Linux, FreeRTOS, МСВС. Соответственно есть своя библиотека, выполняющая в том числе функции слоя совместимости.
Так что перевод под liux — это в основном замена нескольких инклудов. Могу в личку патч кинуть. Ну и makefile сделать путем cut&paste. Работа простая и быстрая.
Чтение статей в вашем блоге показывает, что на понимание диагностик PVS-Studio и принятие решения о правки (или отключении предупреждения) требуется время от 5 минут до получаса. Много очень тонких ошибок, про которые сложно понять, баги или не баги.
С другой стороны, у меня много опыта в портировании, а у вас — в анализе предупреждений.
В целом оценки такие. На чуть более тысячи строк кода — полчаса на портирование под linux, 3 часа — на исправление 33 предупреждений, которые нарыл gcc. Но все это время — оправдывается.
А вот cppcheck — не оправдывается даже затраченное на него время. Тех ошибок, что видит gcc, он не замечает в упор (видимо by design он не дублирует gcc). Например — неполный перечень значений перечислимого типа в switch.
Так что перевод под liux — это в основном замена нескольких инклудов. Могу в личку патч кинуть. Ну и makefile сделать путем cut&paste. Работа простая и быстрая.
Чтение статей в вашем блоге показывает, что на понимание диагностик PVS-Studio и принятие решения о правки (или отключении предупреждения) требуется время от 5 минут до получаса. Много очень тонких ошибок, про которые сложно понять, баги или не баги.
С другой стороны, у меня много опыта в портировании, а у вас — в анализе предупреждений.
В целом оценки такие. На чуть более тысячи строк кода — полчаса на портирование под linux, 3 часа — на исправление 33 предупреждений, которые нарыл gcc. Но все это время — оправдывается.
А вот cppcheck — не оправдывается даже затраченное на него время. Тех ошибок, что видит gcc, он не замечает в упор (видимо by design он не дублирует gcc). Например — неполный перечень значений перечислимого типа в switch.
Чтение статей в вашем блоге показывает, что на понимание диагностик PVS-Studio и принятие решения о правки (или отключении предупреждения) требуется время от 5 минут до получаса.
Замечу, что это высказывание показывает, что Jef239 не работал с PVS. На самом деле такое может быть при работе с незнакомым кодом. При работе со своим кодом, например при инкрементальной компиляции, обычно требуется несколько секунд, чтобы понять, что ты тут налажал, ну и до 30 секунд, чтобы понять, что тут реально ложняк. И тонких ошибок в своём коде как таковых нет, само это понятие, думаю применяется, в смысле «что-то не очень понятное с первого взгляда незнакомому человеку, но на пол взгляда разработчику этого кода».
P.S. Ценник на самом деле высоковат :-(. Никак не удаётся через руководство протащить :-(. Здесь, наверное, просится 2 прайса, один в евро, второй в рублях, и чтобы в рублях он был адекватен к российским реалиям.
Да, при инкрементальной проверке время будет меньше. Но не секунды. Читая ваш блог, я постоянно вижу ситуации, когда код понятен, а на что ругнулся анализатор — нет. И только спустя минуты приходит понимание, что анализатор-то прав.
Это все зависит от темпа мышления. Мне уже 50 лет, в 20 темп мышления был быстрее, зато опыта было меньше.
Тонкие ошибки — ну, например, copy-paste, когда имена очень похожи и в одной строке забыли исправить имя. Взгляд замыливается и ошибка не видна. У PVS-Studio была отдельная статья про этот эффект.
У меня была ошибка, когда при включении оптимизации -O3 gcc ругался на вход индекса за пределы массива при развертывании циклов. Месяца через два дошло, что gcc прав и при некоторых значениях параметров действительно будет выход за пределы массива.
Так что намеренные мной времена — довольно типичные. Опыт с PVS-studo на том же коде дал аналогичные результаты. Было найдено 5 однотипных ошибок, время на понимание — те же 5 минут. Правда после понимания первой ошибки, остальные были исправлены быстро.
Да, для мелкого бизнеса ценник не соответствует пользе от анализатора. Уже писали что на программах до 250 Kloc пользы от анализатора не так много. Возможно стоит ввести отдельный прайс для малых фирм.
Мне вот хочется попробовать найти заброшенный вами cppcat и посмотреть пользу от него.
Пока что выводы прежние — для проектов до 100KLoc самое эффективное это -wall -wextra.
Это все зависит от темпа мышления. Мне уже 50 лет, в 20 темп мышления был быстрее, зато опыта было меньше.
Тонкие ошибки — ну, например, copy-paste, когда имена очень похожи и в одной строке забыли исправить имя. Взгляд замыливается и ошибка не видна. У PVS-Studio была отдельная статья про этот эффект.
У меня была ошибка, когда при включении оптимизации -O3 gcc ругался на вход индекса за пределы массива при развертывании циклов. Месяца через два дошло, что gcc прав и при некоторых значениях параметров действительно будет выход за пределы массива.
Так что намеренные мной времена — довольно типичные. Опыт с PVS-studo на том же коде дал аналогичные результаты. Было найдено 5 однотипных ошибок, время на понимание — те же 5 минут. Правда после понимания первой ошибки, остальные были исправлены быстро.
Да, для мелкого бизнеса ценник не соответствует пользе от анализатора. Уже писали что на программах до 250 Kloc пользы от анализатора не так много. Возможно стоит ввести отдельный прайс для малых фирм.
Мне вот хочется попробовать найти заброшенный вами cppcat и посмотреть пользу от него.
Пока что выводы прежние — для проектов до 100KLoc самое эффективное это -wall -wextra.
Насколько увеличились продажи?
Повторюсь: (к счастью) это не моя задача.
Со "сдачей проекта" уже не всё так просто. Скажем, почти всегда проще и быстрее воткнуть костыль. Если же планируется долгая жизнь проекта, то накопившаяся гора костылей может больно аукнуться.
Мой опыт такой, что если цейтнот постоянно, то что-то делается неправильно и страдать будет как качество, так и такая "эфемерная" штука "удовольствие от работы" (ну или "уровень стресса"). В итоге сотрудники будут перегорать и разбегаться. Ну это если аргумент про "некогда точить, пилить надо!" не принимается. А если периодически выделяется время на разгребание накопившихся проблем и прочий рефакторинг, то найдётся и на то чтобы прикрутить анализатор и задавить имеющиеся предупреждения. Что касается цены, так на прошлом месте работы выбирали между PVS и Coverity и надо сказать, что второй инструмент стоит на порядок дороже.
Впрочем, вы говорите о "завершении проекта". Возможно, у нас сильно разный опыт, так как, в основном, сталкивался с (потенциально) "бесконечными" проектами. Впрочем, это не значит отсутствие своих релизов/дедлайнов. Но опять же, в моей практике, с какого-то момента это всё окупается, тем более, что ресурсы на интеграцию придётся потратить один раз.
Аргумент про ошибки в ТЗ мне совершенно не понятен. В том плане, что серебряной пули не бывает и все проблемы не решит ни один инструмент, но из этого никак не следует бесполезность этих самых инструментов.
Увы, ни одного аргумента я от вас не услышал, только голые заявления о полезности.
Хотя и ожидал услышать конкретные цифры вроде на анализ и правку найденного тратиться Х часов в неделю, из найденного K% оказалось критичным, что привело к экономии Yчасов в неделю. И вывод, что Y настолько больше Х, что стоит платить. Ну или не стоит.
В качестве развлечения — можете убедить авторов PVS-Studio разок проверить свое творение при помощи valgtind. Динамический анализ хорош тем, что ловит ошибки на «главному пути», то есть найденное им действительно нуждается в исправлении.
Вопросы управления техническим долгом — это отдельная тема для обсуждения. Что касается цейтнота, то я просто за 30 лет работы так и научился работать от сих до до сих. Или уж как в понедельнике — или менять работу.
Серебряной пули нет, но есть ошибки важные и неважные. Если при обновлении прошивки в датчике проект перестает получать от него данные — это важно. А если программа ломается при командной строке длиннее 4 килобайт — это неважно, потому что командную строку пишем мы сами. И если уж злоумышленник долез до командной строки — он может с тем же успехом и топором ударить.
При вагоне свободного времени у сотрудников и бесплатности инструментов — любой инструмент будет полезен. А как только рабочее время и инструмент стновятся платными — так сразу и возникает вопрос о полезности отдельных инструментов.
Вы осциллограф себе для отладки купили? А ведь он полезен! Вот только для вас он полезен абстрактно, а для нас — конкретно. Как простейший пример — вместо того, чтобы гадать — то ли провод сдох, то ли воткнули криво, то ли сбой в программе — можно просто посмотреть, идет ли сигнал.
Ну вот пока что полезность PVS-Studio для нас — на уровне полезности осциллографа для вас.
Хотя и ожидал услышать конкретные цифры вроде на анализ и правку найденного тратиться Х часов в неделю, из найденного K% оказалось критичным, что привело к экономии Yчасов в неделю. И вывод, что Y настолько больше Х, что стоит платить. Ну или не стоит.
В качестве развлечения — можете убедить авторов PVS-Studio разок проверить свое творение при помощи valgtind. Динамический анализ хорош тем, что ловит ошибки на «главному пути», то есть найденное им действительно нуждается в исправлении.
Вопросы управления техническим долгом — это отдельная тема для обсуждения. Что касается цейтнота, то я просто за 30 лет работы так и научился работать от сих до до сих. Или уж как в понедельнике — или менять работу.
Серебряной пули нет, но есть ошибки важные и неважные. Если при обновлении прошивки в датчике проект перестает получать от него данные — это важно. А если программа ломается при командной строке длиннее 4 килобайт — это неважно, потому что командную строку пишем мы сами. И если уж злоумышленник долез до командной строки — он может с тем же успехом и топором ударить.
При вагоне свободного времени у сотрудников и бесплатности инструментов — любой инструмент будет полезен. А как только рабочее время и инструмент стновятся платными — так сразу и возникает вопрос о полезности отдельных инструментов.
Вы осциллограф себе для отладки купили? А ведь он полезен! Вот только для вас он полезен абстрактно, а для нас — конкретно. Как простейший пример — вместо того, чтобы гадать — то ли провод сдох, то ли воткнули криво, то ли сбой в программе — можно просто посмотреть, идет ли сигнал.
Ну вот пока что полезность PVS-Studio для нас — на уровне полезности осциллографа для вас.
Хотя и ожидал услышать конкретные цифры...
Как вы себе это представляете? Даже если бы кто-то и решился на такой эксперимент, то как обеспечить объективность? Ведь нельзя дважды написать одинаковый код одинаковыми людьми в одинаковых обстоятельствах, но в одном случае использовать статический анализатор.
потому что командную строку пишем мы сами...
С чего вы решили, что я собираюсь доказывать нужность инструмента конкретно вам? Или вообще кому-либо. Понятное дело, что ситуации бывают разные, я просто напомню контекст: в моём окружении люди понимают ценность статического анализатора (собственно сейчас вообще на расте пишу по аналогичным причинам). Всё. Разумеется, глобальных выводов из этого делать нельзя, точно так же, как и из вашей аргументации.
Вы осциллограф себе для отладки купили? А ведь он полезен! Вот только для вас он полезен абстрактно, а для нас — конкретно.
Передёргивание. Осциллограф полезен для ограниченного числа ситуаций/проектов, статический анализатор — практически для любого кода. Размер этой пользы (и "стоимость") можно обсуждать, но отрицать её целиком мне кажется странным.
Ну и уточню ещё один момент касательно "стоимости": если у нас на проекте (условно) два человека, то да, это всё дорого, сложно и некогда. А если под сотню, то анализатор стоит копейки относительно всех затрат.
Легко представляю. Просто не надо стремиться к лишней точности. Вот вам анализ для -Wall -Wextra.
50% варнингов и 10% хинтов — это реальные ошибки. Процентов 80 из них — на главном ходу, то есть обязательно должны быть найдены и исправлены. Среднее время на исправление замечания gcc — 3 минуты. Среднее время на нахождение и исправление бага тестированием — 1 час.
Теперь считаем на 100 варнигов. В пассиве — 100 на 3 минуты — 5 часов на обработку. В активе 100 * 50% * 80% + 1 час = 40 часов. 40/5 — 8 раз. Вот в 8 раз -Wall лучше -w.
Считаем на 100 хинтовв. В пассиве — 100 на 3 минуты — 5 часов на обработку. В активе 100 * 10% * 80% + 1 час = 8 часов. 8/5 — 1.6 раза. Вот в 1.6 раза -Wextra лучше.
Разумеется, все это очень приблизительно. По варнингам может быть и не 8 раз, а 5. Или 15. По хинтам может быть и 0.9 и 3. Но примерно — расклад такой.
В моем окружении понимание чего-либо начинается с возможности доказать свою точку зрения и подтвердить её расчетами. А все остальное — это вера. Ну или суеверие. С другой стороны интуиция опытного инженера — это вещь, которой лучше доверять, чем не доверять. Даже если она основана на вере.
А вы оглянитесь вокруг себя. Микроволновка, стиральная машина, лифт, кодовый замок… всюду вокруг вас — embeded. То есть устройства, к которым проще подключить осциллограф, чем организовать вывод на консоль. Фактически, как только вы уходи с linux на freeRTOS или голое железо — так сразу есть смысл начать просчитывать выгоду от осциллографа.
С другой стороны, есть несколько замечаний от авторов PVS-Studio:
Если сильно нужно — найду ссылки, где об этом написано.
А вот тут согласен. При сотне девелоперов цена анализатора будет равна 2-4 дням работы девелоперов. А количество ошибок — прилично растет.
50% варнингов и 10% хинтов — это реальные ошибки. Процентов 80 из них — на главном ходу, то есть обязательно должны быть найдены и исправлены. Среднее время на исправление замечания gcc — 3 минуты. Среднее время на нахождение и исправление бага тестированием — 1 час.
Теперь считаем на 100 варнигов. В пассиве — 100 на 3 минуты — 5 часов на обработку. В активе 100 * 50% * 80% + 1 час = 40 часов. 40/5 — 8 раз. Вот в 8 раз -Wall лучше -w.
Считаем на 100 хинтовв. В пассиве — 100 на 3 минуты — 5 часов на обработку. В активе 100 * 10% * 80% + 1 час = 8 часов. 8/5 — 1.6 раза. Вот в 1.6 раза -Wextra лучше.
Разумеется, все это очень приблизительно. По варнингам может быть и не 8 раз, а 5. Или 15. По хинтам может быть и 0.9 и 3. Но примерно — расклад такой.
в моём окружении люди понимают ценность статического анализатора
В моем окружении понимание чего-либо начинается с возможности доказать свою точку зрения и подтвердить её расчетами. А все остальное — это вера. Ну или суеверие. С другой стороны интуиция опытного инженера — это вещь, которой лучше доверять, чем не доверять. Даже если она основана на вере.
Осциллограф полезен для ограниченного числа ситуаций/проектов, статический анализатор — практически для любого кода
А вы оглянитесь вокруг себя. Микроволновка, стиральная машина, лифт, кодовый замок… всюду вокруг вас — embeded. То есть устройства, к которым проще подключить осциллограф, чем организовать вывод на консоль. Фактически, как только вы уходи с linux на freeRTOS или голое железо — так сразу есть смысл начать просчитывать выгоду от осциллографа.
С другой стороны, есть несколько замечаний от авторов PVS-Studio:
- До 250 тысяч строк PVS-Studio не оправдывается.
- Пока у кода есть конкретные авторы, которые помнят код целиком — PVS-Studio не оправдывается.
- Там, где нет динамического выделения памяти (то есть embeded) PVS-Studio не оправдывается.
Если сильно нужно — найду ссылки, где об этом написано.
А если под сотню, то анализатор стоит копейки относительно всех затрат.
А вот тут согласен. При сотне девелоперов цена анализатора будет равна 2-4 дням работы девелоперов. А количество ошибок — прилично растет.
Легко представляю. Просто не надо стремиться к лишней точности.
Ну да, так что-то посчитать можно, но у меня вызывает сомнение полезность таких грубых прикидок. В любом случае, временный ключ авторы выдают по запросу, если очень интересно, то можно и посмотреть на своём проекте. Или вы хотите чтобы это кто-то другой для вас сделал? (:
А вы оглянитесь вокруг себя. Микроволновка, стиральная машина, лифт, кодовый замок…
Дык, я не говорю, что осциллограф бесполезен всем. Хотя всё-таки кажется, что если считать "проекты" или, тем более, строки кода, то железячных проектов окажется меньше.
Если сильно нужно — найду ссылки, где об этом написано.
Тоже что-то такое припоминаю и возражений нет — звучит вполне логично. Если это ваш случай, ну что ж, не нужен инструмент и ладно.
если очень интересно, то можно и посмотреть на своём проекте
Судя по лицензии, есть только один честный способ использования демо-версии — попробовать перед покупкой. А использование без цели покупки — это пиратство. Ну как-то не привык я пиратить программы российских разработчиков.
меня вызывает сомнение полезность таких грубых прикидок.
Почему же? Вы когда машину покупаете, что вначале делаете? Тест-драйв или в интернете отзывы ищете? А тут ещё и неизвестный гаджет. Так что отзывы прежде всего. Производитель — он всегда себя нахвалит. А на деле — бывает иначе…
В любом случае, для почти всех типов систем анализ эффективности внедрения — это курсовая или глава в дипломе. Есть методики, есть расчеты, и они делаются до покупки. И мы почти в каждом договоре такой раздел пишем. А вот на статанализаторы методики нет. И то, что авторы PVS-Studio её не придумали — намекает, что с эффективностью плохо…
если считать «проекты» или, тем более, строки кода, то железячных проектов окажется меньше.
Если помножить строки кода на количество экземпляров… Ну вообще-то в каждой флэшке — 1-2 процессора. Один для общения по USB, а второй — для равномерной нагрузки на сектора flash. В вашем мобильнике — процессоров десяток. Тот же GPS-приемник — это 1-2 процессора (DSP+ARM). Сейчас проще запихнуть процессор, чем делать аналоговым путем.
Но я соглашусь с тем, что это ненастоящее программирование… Когда причиной бага оказывается лишняя капля припоя на ножках процессора — это уже ближе к радиотехнике…
Собственно то, что я вижу в блоге PVS-Studio — это антиреклама. Берут большой проект, проверяют, находят какую-то мелочевку. Ни одного случая, чтобы нашли какой-то важный баг, который пользователи постоянно репортят, я не видел. Судя по их блогу PVS-Studio еле-еле оправдывает время, потраченное на проверку проекта и исправление кода. Ну или не оправдывает.
Конечно, если у нас управление атомным реактором или космическим кораблем — стоит применять все инструменты для поиска багов. Но это как раз редкость ещё большая, чем осциллограф при отладке.
Я надеялся, что вы опровергните это мнение. Но увы, видимо не получится.
Ещё раз повторю, что на мой взгляд 95% выгоды от статанализа дает компиляция программы разными компиляторами с максимальными предупреждениями. Более того, авторы PVS-Studio при доказательствах полезности регулярно ссылаются на те диагностики, что есть в компиляторах.
Конечно, если у нас управление атомным реактором или космическим кораблем — стоит применять все инструменты для поиска багов. Но это как раз редкость ещё большая, чем осциллограф при отладке.
Я надеялся, что вы опровергните это мнение. Но увы, видимо не получится.
Ещё раз повторю, что на мой взгляд 95% выгоды от статанализа дает компиляция программы разными компиляторами с максимальными предупреждениями. Более того, авторы PVS-Studio при доказательствах полезности регулярно ссылаются на те диагностики, что есть в компиляторах.
Эмм, если пользователи зарепортили какой-то баг, то его уже задебажили и исправили.
Собственно PVS об этом и говорят, что можно все баги исправлять с помощью дебага, но дешевле купить их анализатор.
Да ну? В открытых программах иногда баги больше 5 лет висят. Особенно, если баг мешает только русскоязычным пользователям. Да и в закрытых… Помнится был некий текст, после набора которого ворд вылетал…
Увы, есть баги, которые можно очень долго искать. Например: состояние гонки, редкая порча случайного места памяти… Динамический анализ в этих ситуациях несколько помогает, статический — не очень.
Ну вот и докажите, что дешевле. Последняя известная цена анализатора — 600 тысяч рублей. Ну вот и докажите, что он нашел багов на миллион или больше в год.
Если у вас тысяча программистов — вполне верится, что анализатор дешевле. А когда четверо?
Пока что все попытки использовать бесплатный cppcheck показали, что он не оправдывает даже время, потраченное на анализ его логов и исправление кода.
Увы, есть баги, которые можно очень долго искать. Например: состояние гонки, редкая порча случайного места памяти… Динамический анализ в этих ситуациях несколько помогает, статический — не очень.
все баги исправлять с помощью дебага, но дешевле купить их анализатор.
Ну вот и докажите, что дешевле. Последняя известная цена анализатора — 600 тысяч рублей. Ну вот и докажите, что он нашел багов на миллион или больше в год.
Если у вас тысяча программистов — вполне верится, что анализатор дешевле. А когда четверо?
Пока что все попытки использовать бесплатный cppcheck показали, что он не оправдывает даже время, потраченное на анализ его логов и исправление кода.
Я надеялся, что вы опровергните это мнение. Но увы, видимо не получится.
Да, не получится.
Более того: если посмотреть на факты, то мы легко к соглашению придём. Вот только выводы делаем разные.
Ну и чтобы два раза не вставать: с какого-то момента, меня (тоже?) данная реклама стала слегка раздражать. Но надо отдать должное: продукт они делают востребованный (иначе разорились бы) и качественный. И как для рекламных статей, технических деталей даже много. (:
Меня раздражает не реклама, а её расхождение с выводами её авторов. Сами статьи говорят о том, что продукты работают и успешно используются несмотря на кучу мелких недочетов. А авторы пытаются впарить, что без статанализатора — никак, что статанализатор способен найти действительно важные проблемы, а не эту кучу мелочей.
У меня такое впечатление, что скоро они к куче уже признанных ими менеджерских ошибок добавят ещё одну: отсутствие образа потребителя.
Проверим? Был бы выгоден для вас PVS-Studio при наличии четырех разработчиков в команде?
У меня такое впечатление, что скоро они к куче уже признанных ими менеджерских ошибок добавят ещё одну: отсутствие образа потребителя.
Более того: если посмотреть на факты, то мы легко к соглашению придём. Вот только выводы делаем разные.
Проверим? Был бы выгоден для вас PVS-Studio при наличии четырех разработчиков в команде?
Ну вот вам пример, чего бы мне хотелось. Нашумевший баг Intel AMT
computed_response вычитывается из ПЗУ, user_response — принимается по сети, длина берется от user_response — и получаем жирный баг.
Теоретически статический анализ может понять, где ввод пользователя, а где — записанный пароль. Практически — мне не верится, PVS-Studio это поймает. Но даже если оно скажет, что в качестве длины надо использовать max от длин строк — это уже полезно.
Вот что-то такого уровня важности у вас статанализ ловил? Увы, в блогах я настолько жирных примеров не видел. И вообще, не видел ни одного примера, когда публикация статьи откладывалась из-за нахождения реальной, крупной уязвимости.
if(strncmp(computed_response, user_response, response_length))
exit(0x99);
computed_response вычитывается из ПЗУ, user_response — принимается по сети, длина берется от user_response — и получаем жирный баг.
Теоретически статический анализ может понять, где ввод пользователя, а где — записанный пароль. Практически — мне не верится, PVS-Studio это поймает. Но даже если оно скажет, что в качестве длины надо использовать max от длин строк — это уже полезно.
Вот что-то такого уровня важности у вас статанализ ловил? Увы, в блогах я настолько жирных примеров не видел. И вообще, не видел ни одного примера, когда публикация статьи откладывалась из-за нахождения реальной, крупной уязвимости.
Хотя и ожидал услышать конкретные цифрыPVS-Studio ROI: как не терять миллионы.
Чуть-чуть про осциллограф при отладке. Помимо абстрактной полезности есть условия, когда польза от осциллографа намного превышает его цену. Это ситуации:
В итоге получается довольно узкая область, для которой осциллограф must have. Причем не только стационарный, но и переносной — для полевых испытаний.
Вот такую вот область для PVS-Studio я и хочу очертить.
Но пока что мое мнение — 95% пользы от статанализа дает проверка несколькими компиляторами с выключенными на максимум предупреждениями. Остальное — для нас не оправдывает цену.
Возможно, оправдаетсяпиратское использование бесплатной демо-версии PVS-Studio. Но тут уже вопрос лицензии и собственной совести. Ну как бы демо-версия — она только для оценки перед покупкой.
- Когда используется кастомное железо (свое или заказное) и баг в железе (или в соединениях) столь же вероятен, как и баг в софте.
- Когда вывод в лог более трудоемок, чем вывод на GPIO. Например, чтобы посмотреть время обработки между приемом данных и выводом, можно задействовать высокоскоростной таймер, сделать усреднение, определение пиков… А можно установить 1 при приеме данных и 0 при окончании обработки. И сразу будет видно, нет ли задержек, всегда ли обработка успевает, как влияют нагрузка на другие нити...
- Когда программисты или в детстве были радиолюбителями или имеют радио-образование.
В итоге получается довольно узкая область, для которой осциллограф must have. Причем не только стационарный, но и переносной — для полевых испытаний.
Вот такую вот область для PVS-Studio я и хочу очертить.
Но пока что мое мнение — 95% пользы от статанализа дает проверка несколькими компиляторами с выключенными на максимум предупреждениями. Остальное — для нас не оправдывает цену.
Возможно, оправдается
Возможно, оправдается сквозное проветривание помещения, чтоб код не пах. Но тут уже вопрос веры и собственной адекватности. Ну как бы проветривание — оно только для улучшения условий труда.
Но пока что мое мнение — 95% пользы от статанализа дает проверка несколькими компиляторами с выключенными на максимум предупреждениями.
Вы забыли соответствующую опцию указать, я помогу :D
3.8 Options to Request or Suppress Warnings
-w
Inhibit all warning messages.
Может пора требовать от Микрософта перед релизом Windows 11 анализаторами прочесывать?
Тогда гляди уязвимостей на порядок уменьшится, а скорость и стабильность увеличится.
И не надо будет патчи и сервис-паки каждый день клепать.
Тогда гляди уязвимостей на порядок уменьшится, а скорость и стабильность увеличится.
И не надо будет патчи и сервис-паки каждый день клепать.
А странные сигнатуры operator++ и operator-- вы не видите смысла детектить?
Объект типа CString создаётся и инициализируется, но нигде не используется. Не знаю, догадается ли компилятор выбросить лишний код для создания и копирования строки.
Открою секрет. CString, как и QString, как и std::string в GCC < 5.0* не копируют строку при присваивании. Там везде COW (Copy-On-Write). И все студийные компиляторы от 2005 в релизе эту переменную типа CString убирают, я специально ещё N лет назад проверял. Но неиспользуемую переменную, конечно, удалить в любом случае всё равно надо.
*Только C++11 потребовал чтобы для std::string было нормальное поведение. Поэтому в gcc 5 std::string сделали как везде.
Предупреждение PVS-Studio: V665 Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The '#pragma warning(push/pop)' should be used instead. Check lines: 2610, 2628. mmreg.h 2628
Если быть педантичным, то mmreg.h к «Visual C++ 2017 Libraries» отношения не имеет никакого. mmreg.h — это часть Windows SDK. Этот файл доступен любому компилятору (хоть gcc, хоть C++ builder).
Sign up to leave a comment.
Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries