Comments 43
По первому комментарию — как только программист говорит что он профессионал и ему тулзов не надо, его можно списывать.
Я бы не был так категоричен (списывать), но это вполне популярная стадия развития программиста. Через некоторое время большинство таких «профессионалов» понимают свои ограничения.
Если это миддл, или сениор, от которого мало что зависит, то можно оставить его в покое какое-то время, сам опомнится. Если же это руководитель/тимлид, то тут конечно лучше действовать более кардинально.
Если это миддл, или сениор, от которого мало что зависит, то можно оставить его в покое какое-то время, сам опомнится. Если же это руководитель/тимлид, то тут конечно лучше действовать более кардинально.
А что делать, если у человека реально один баг на 10 тысяч строк? Лезть в нему в сорцы и впихивать баги искусственно? :-)
Тогда он гений, и ему не нужен анализатор, а агромадный памятник. А потом, после изменения в зависимой библиотеке, переноса на другую платформу, и т.д. можно будет этот памятник снести.
Ну или он просто так думает что у него один баг на 10 тысяч строк.
Ну или он просто так думает что у него один баг на 10 тысяч строк.
Не гений, а просто embedчик. У такого написания кода есть свои минусы:
Но с переносом у него проблем нет.
В чем у вас проблемы с переносом — я не знаю. Скорее всего вы просто не думали о переносе до написания кода.
- Почти нету слоя диагностики
- Проще переписать код, чем найти баг.
- Пишется раз в 10 медленней, с учетом отсутствия трат времени на отладку — примерно баш на баш.
Но с переносом у него проблем нет.
В чем у вас проблемы с переносом — я не знаю. Скорее всего вы просто не думали о переносе до написания кода.
Он пишет на ассемблере, что ли?)
Что такое проект, если не секрет? Драйвер — это проект? Подсистема или библиотека, лежащая в отдельном репозитарии — это проект? Системный слой (FreeRTOS + HAL + драйвера + обвязка) — это проект? Или проект — это все, что компилируется вместе в один бинарник? Или все, загружаемое в одну железку (3-4 процессора) — это один проект?
Если первое — то там проекты (модули) по паре сотен строк. Если последнее — то ближе к полмиллиону.
Сложно понять, что вы называете «проектом». :-) Embeded — оно такое…
Если первое — то там проекты (модули) по паре сотен строк. Если последнее — то ближе к полмиллиону.
Сложно понять, что вы называете «проектом». :-) Embeded — оно такое…
Слушайте, по-моему, все, кто следит за этим блогом, да и просто те, кто встречает ваши комментарии, поняли, что вы занимаетесь embedded-системами (кстати говоря, несмотря на ваш вечный снобизм, это никак вас не выделяет из среды моих и ваших коллег). Надеюсь, вы понимаете, что у embedded своя специфика, и экстраполировать свой опыт в другие области несколько… некорректно?
Мне кажется, что вы все перепутали. В отличие от коллеги, я не embedчик, 98-99 процентам моего кода все равно, где исполняться. Да и экстраполировал понятие «проект» не я, а Whuthering.
Впрочем, могу и экстраполировать. Скажите Microsft Office это проект? Или проектом является Word? Или проект — это подсистема проверки орфографии? Или проект — это библиотека, используемая в нескольких программах? Или проект — это отдельный модуль c template, используемый в нескольких библиотеках?
Как видите — ничего специфического для embeded тут нет.
Впрочем, могу и экстраполировать. Скажите Microsft Office это проект? Или проектом является Word? Или проект — это подсистема проверки орфографии? Или проект — это библиотека, используемая в нескольких программах? Или проект — это отдельный модуль c template, используемый в нескольких библиотеках?
Как видите — ничего специфического для embeded тут нет.
И за употребление слова «нубас» тоже.
Мне бы хотелось добавить, что, как и у всех инструментов, у статических анализаторов есть как положительные, так и отрицательные стороны. В ответственном подходе к разработке программного обеспечения, разумеется, стоит использовать те положительные черты инструмента, что им предоставлены. На моем личном опыте могу сказать одно, статический анализ далеко не раз позволял избежать ошибок и исправить их задолго до наступления негативных последствий.
Что-то это мне напоминает…
Вообще очень полезно заменять слова PVS-Studio (или статический анализатор) словом молитва. Как правило, смысл при этом не меняется. :-)
Но когда польза молитвы и добрых дел доказана уже и учеными, остается только один вопрос. Почему, чтобы во что-то поверить, людям нужно это потрогать? Ведь потрогать можно далеко не все, а тем более увидеть. Но, тем не менее, абсолютно каждый человек, вышедший из храма после искренней молитвы, ощущает легкость, спокойствие и любовь. Вообще очень полезно заменять слова PVS-Studio (или статический анализатор) словом молитва. Как правило, смысл при этом не меняется. :-)
Ниша широка, и в ней замечательно помещается не только анализатор PVS-Studio,Что-то изменилось за 2.5 года?
очень недорогой анализатор под названием CppCat. Сейчас можно подвести итоги этого эксперимента и признать, что он оказался неудачным. За срок чуть более года он принёс приблизительно столько денег, сколько было потрачено на его разработку, продвижение и поддержку. Таким образом проект убыточен. Главная ваша ошибка — очень мало кого интересует абстрактная польза. Интересует польза на рубль затрат.
- Не меньше 250 тысяч строк в проекте
- Не меньше 50 разработчиков
процент ложных срабатываний у хороших анализаторов намного меньше, чем у компилятора.У хороших (то есть дорогих) — да. Тот же PVS-Studio на небольшом тесте вообще не дал ложных срабатываний. Зато бесплатный cppcheck не оправдывает время на анализ его предупреждений.
Попробуйте скомпилировать свой код другим, еще не используемым ранее компилятором, и вы получите те же тысячи, а то и десятки тысяч предупрежденийЕсли первый компилятор — не Visual Studio, то предупреждений будет намного меньше. После третьего компилятора — их количество (на четвертом, пятом и так далее) вообще стремится к нулю.
Так вот, отказаться от статического анализа так же глупо, как выключить все предупреждения компилятора.
Это очень глубокое заблуждение. Да, личный самолет — круче велосипеда. Но в булочную на нем ездить как-то неэффективно. Да, для личной странички можно заказать дизанй у Артемия Лебедева. Но будет ли это эффективно? Предупреждения компилятора бесплатны, ибо компилятор уже куплен. А PVS-Studio стоит килобаксы.
Правильнее говорить так — отказываться от пиратского PVS-studio не стоит. А покупать или нет — зависит от цены ошибок, найденных на каждый рубль, вложенный в PVS-studio. И сравнения этой цены с тестами, динамическим анализом и так далее. И в большинстве случаев для малой компании PVS-Studio будет невыгоден. А судя по опыту cppcat — невыгоден и статический анализ вообще.
Если кто-то скажет, что предупреждения компилятора дают ему ложное чувство безопасности, то это проблема говорящего, а не компилятора.Это проблема менеджмента. Деньги на PVS-Studio не берутся из воздуха, а идут за счет иных средств поиска ошибок. И если вы уволили тестеров, а взамен купили PVS-studio — общий эффект скорее всего будет печален.
Здесь вновь уместна аналогия с предупреждениями компилятора. Допустим, полностью отключаются предупреждения, и 3 месяца разрабатывается проект. А затем, за день до релиза, все эти предупреждения компилятора включаются. Согласитесь, это глупость какая-то.
Ваш собственный опыт показал, что ничего ужасного не произошло. :-)
попробовать PVS-Studio очень просто.Если у вас Visual Studio или устроит
По любым возникающим вопросам смело пишите в поддержку.Мы уже полгода ждем ответы. Если вы верите, что вам ответят быстрее — пишите. А если нет — то нет.
По любым возникающим вопросам смело пишите в поддержку.
Мы уже полгода ждем ответы. Если вы верите, что вам ответят быстрее — пишите. А если нет — то нет.
Когда то писал с предложением добавить проверку что функция override-ит, ответили через несколько дней, сейчас вижу что проверка есть. Не корпоративный пользователь.
Это отлично, что вам повезло. А вот нам, чтобы посмотреть PVS-Studio в деле потребовался тестовый ключ для линукс-версии. Полгода ждем. Как думаете, я его до пенсии дождусь? :-)
Мне кажется, что не дождемся. Ибо наша компания дорастет до того размера, когда PVS-studio нам станет выгодным намного позже, чем я умру. То есть мы — не клиент для них. Потому и молчат, как партизаны. Самое интересное, что посылали запрос с незасвеченного мыла, не имеющего отношения к нашей фирме. Все равно не помогло.
пиратский вариант использования?
Мне кажется, что не дождемся. Ибо наша компания дорастет до того размера, когда PVS-studio нам станет выгодным намного позже, чем я умру. То есть мы — не клиент для них. Потому и молчат, как партизаны. Самое интересное, что посылали запрос с незасвеченного мыла, не имеющего отношения к нашей фирме. Все равно не помогло.
Не корпоративный пользователь.Вы потратили личные сотни килобаксов на PVS-Studio? Или это тот самый
Для протокола — с cmake'ом PVS отлично работает.
Угу, работает. Но с двумя известными ему препроцессорами. Нам на беду потребовался третий. :-)
Это, наверное, всё-таки естественный уровень для поддержки коммерческих продуктов.
Естественный уровень продуктов — дока, соответствующая продукту. А это уровень полузаказного решения, где внедрение делают авторы или приближенные к ним.
У программистов обычно никакой ответственности за говнокод нет, ну вылез там где-то null pointer, всем насрать. Запатчат и будут дальше говнокодить.
Это потому что заказчики хотят побыстрее и подешевле, да и сами толком не знают, чего хотят. «Давайте попробуем так, а если что-то не получится, мы вам скажем, в какую сторону двигаться дальше».
И никого не колышет, что написанный корректный код — по сути, доказанная теорема, и, внося, незначительные правки в задание, по хорошему, надо передоказывать (переосмысливать, перепроверять) всё написанное и времени на это нужно примерно столько же, как написать заново.
Запатчить и дальше говнокодить — это то, что устраивает заказчиков по срокам и ценам.
И никого не колышет, что написанный корректный код — по сути, доказанная теорема, и, внося, незначительные правки в задание, по хорошему, надо передоказывать (переосмысливать, перепроверять) всё написанное и времени на это нужно примерно столько же, как написать заново.
Запатчить и дальше говнокодить — это то, что устраивает заказчиков по срокам и ценам.
Мужики, у вас версия для MacOS планируется хоть когда-нибудь? Там не должно быть слишком уж больших отличий от версии для Linux, по идее.
Я понимаю, что картина мира уже сформирована и все неудобные факты остаются вне восприятия. Тем не менее, всё равно вставлю свои 5 копеек.
Я вам уже давно статью обещал, и, собственно, основной вывод этой статьи — в моём опыте Coverity + clang static-analyzer покрывают строгое надмножество проблем, обнаруживаемых PVS'омВот только, что интересно, это не мешает PVS-Studio вновь и вновь находить ошибки в LLVM. См. ссылки в статье. А ведь LLVM, проверяется регулярно Coverity + clang static-analyzer.
Форсинг стат анализа в целом и одного конкретного анализатора в частности, наталкивает на следующие мысли: статический анализ есть в любом зрелом компиляторе. Если его почему-то не хватает, то можно задуматься об использовании более одного компилятора под более чем одну платформу, битность, порядок байт, выравнивание и т.п. Т.е., например, берём Windows под x86, MacOS под x86_64, Linux под PowerPC и компилируем наше поделие несколькими разными компиляторами одновременно (например, VC, clang, gcc). В качестве параноидальной меры, выставляем максимальный уровень предупреждений (желательно только для своего кода) и treat warnings as errors. Получаем некислый поток ошибок, правим код, повторяем. В качестве бонуса получаем кроссплатформенный и кросспроцессорный код, с халявным многоуровневым статическим анализом под разные кейсы. При этом время тратится не на тонкую настройку анализатора (а по сути, на заметание вороха предупреждений под ковёр, в ложной надежде когда-нибудь к ним вернуться), а на написание переносимого кода, который потенциально намного лучше монетизируется.
Это все очень гладко на бумаге, но позволить себе подобное могут только те, у кого проекты либо очень маленькие, либо очень дорогие, либо на них сидит сотня человек и можно бросить десяток на доводку предупреждений многочисленных компиляторов.
В реальности же абсолютное большинство проектов собирается для одной единственной ОС, одним единственным семейством компиляторов, без warnings-as-errors и прочего, и там от внедрения статического анализа (хоть какого-нибудь, не обязательно конкретно PVS-Studio) польза весьма существенная и доступна она практически сразу.
Про предупреждения компиляторов: ну вот пока еще не один не смог предупредить меня, что у меня две функции имеют одинаковое тело, хотя задумывались разными, что у меня результат вызова функции не влияет на проверяемое значение, что у меня в условии продолжения цикла for используется оператор, в смысле &&, а это так не работает на самом деле, что у меня оптимизатор может удалить цикл ожидания на MMIO-регистре, потому что он не помечен как volatile, и вызов memset для затирания данных на стеке тоже может удалить, потому что он не влияет на наблюдаемое поведение.
Понятно, что добрую половину всего вот этого можно получить, разобравшись с миллионом опций своего компилятора, но тут фишка в том, что сама по себе компиляция при этом с большой вероятностью сломается в стольких местах, что никто по доброй воле эти хитрые предупреждения больше никогда не включит.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
В реальности же абсолютное большинство проектов собирается для одной единственной ОС, одним единственным семейством компиляторов, без warnings-as-errors и прочего, и там от внедрения статического анализа (хоть какого-нибудь, не обязательно конкретно PVS-Studio) польза весьма существенная и доступна она практически сразу.
Про предупреждения компиляторов: ну вот пока еще не один не смог предупредить меня, что у меня две функции имеют одинаковое тело, хотя задумывались разными, что у меня результат вызова функции не влияет на проверяемое значение, что у меня в условии продолжения цикла for используется оператор, в смысле &&, а это так не работает на самом деле, что у меня оптимизатор может удалить цикл ожидания на MMIO-регистре, потому что он не помечен как volatile, и вызов memset для затирания данных на стеке тоже может удалить, потому что он не влияет на наблюдаемое поведение.
Понятно, что добрую половину всего вот этого можно получить, разобравшись с миллионом опций своего компилятора, но тут фишка в том, что сама по себе компиляция при этом с большой вероятностью сломается в стольких местах, что никто по доброй воле эти хитрые предупреждения больше никогда не включит.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
Внедрение хорошего статического анализатора туда, где его никогда не было, а код при этом писали на обычном C/C++ (а не на MISRA C с последующей верификацией) обычные люди (не Boeing/Airbus/NASA), за обычные деньги и при постоянного горящих сроках — оно сразу позволяет найти кучу ошибок, просто потому что на танцы с опциями компилятора ни у кого времени нет и никогда не будет.
Я не против статанализа. Скорее за него. Но если есть «халявный» способ и кроссплатформу написать и статанализ улучшить (за счет мультикомпиляции), то почему бы и нет.
И потом, кто сказал, что использование статического анализатора могут позволить себе маленькие коллективы за небольшие деньги? Мой опыт говорит ровно об обратном. Перешагнуть требуемый порог в большом объеме легаси-кода очень и очень и очень-очень непросто и недешево. Есть вариант замести старые ошибки и предупреждения под ковер (это же рекомендует PVS для старых проектов), но это просто мусор под ковром и издевательство над идеей.
Насчет MISRA C (и MISRA C++), то это ни от чего не страхует и ничего не гарантирует. (SIL3 и MISRA у нас тоже практикуются, но к счастью, не в проекте, над которым я работаю).
ЗЫ
Если что, то я о своем опыте ежедневной работы написал.
Насчет MISRA C (и MISRA C++), то это ни от чего не страхует и ничего не гарантируетНе гарантирует, но страхует. Насколько — зависит от обычного стиля и привычек программиста.
И потом, кто сказал, что использование статического анализатора могут позволить себе маленькие коллективы за небольшие деньги? Мой опыт говорит ровно об обратном.Вот-вот, и я об этом. Статанализатор — хорошая штука, но экономически для малых команд выгодней другие меры,
Теоретически звучит красиво, но несовместимо с реальностью. Думаю, многие программисты (и некоторые наши клиенты) посмеются над таким наивным предложением. В рамках больших проектов тяжело даже перейти с одной версии компилятора на следующую. Ни о какой сборке несколькими компиляторами речь даже не идёт. И не потому что код проектов плохой, а потому, что большой, старый и сложный. В добавок, большие проекты, это не абстрактный конь код в вакууме, а активное использование больших сторонних библиотек, которые могут быть в шоке, что их кто-то собрался собирать, чем-то непредусмотренным.
Теоретически звучит красиво, но несовместимо с реальностью.
Ну я вроде не под кайфом работаю. Для меня это ежедневная практика.
В рамках больших проектов тяжело даже перейти с одной версии компилятора на следующую
Качество кода — оно такое, да.
большие проекты, это не абстрактный конь код в вакууме, а активное использование больших сторонних библиотек,
В проекте, с которым работаю я уже около 500 KSLOC (по метрике VisualStudio). И именно по этой причине у нас очень строгие правила насчет того, чтобы тянуть в проект сторонние библиотеки, отличные от stl.
В рамках больших проектов тяжело даже перейти с одной версии компилятора на следующуюВидимо привязка кода к конкретной версии компилятора — это еще одно требование, при котором PVS-Studio становится выгодным.
Динамический анализ действительно является конкурентом статическому и именно из-за того, что он его дополняет. Диалектика, ничего не поделаешь. Тот, кто предложит комплексное решение, в котором динамический анализ учитывает данные статического, а статический — динамического, получит техническое преимущество по сравнению с тем, кто предлагает однобокие решения.
Sign up to leave a comment.
Дискуссия о статическом анализе кода