Комментарии 30
После чтения Ваших статей у меня всегда возникает вопрос — а Вы уверены, что PVS-Studio мало покупают потому, что не верят в его эффективность? Мне кажется, что в способности PVS-Studio найти проблемы в коде уже никто не сомневается. Может надо что-то еще продвигать? Например, стоимость ошибки разработчика.
Сложно. Но мы попробуем.
Есть кое-какой материал о стоимости ошибки в коде, из которого следует вполне очевидный вывод (продвигаемый нами): стоимость исправления ошибки в коде сразу в разы дешевле, чем когда ошибка доходит до тестеров разных уровней и тем более до клиентов. Что-то конкретное сказать для проверенного проекта сложно без внутренней информации о компании.
Хороший хитрый план: зачем исправлять ошибки, выложим код на Github, пусть сообщество правит. Ну тут хоть открыты проект, а игры, которые выпускают до ужаса забагованными — это просто бич отрасли
И Pull Request'ы отрпавили с исправлениями, но у них там завал, никто не закрывает задачи и не рассматривает исправления. Хотя код постоянно редактируют.
Да, переписку ведут :) Нет бы, чтобы сразу написать, в чём был затык и для чего сделан хак — везде только «ask somehow for details».
Им сейчас не до Гитхаба.
Ваше утветржение очень глупое и показывает ваш узкой кругозор и узкое мышление.
1) Этот код может вообще не вызываться и висеть рудиментом.
2) Фиксить баги сложнее, чем писать функционал. И никто в опсосных проектах не будет фиксить баги просто так.
3) Выложили в опенсорс для того, чтобы люди могли изучить код и посмотреть что-нибудь. Всё равно такого зверя писать с ходу никто не будет.
4) Чем больше проект, тем больше в нем приколов и недоумений.
Есть подозрение, что здесь не ошибка, а поиск конца списка. Очевидно, что для большей прозрачности и защиты от случайных ошибок нужно было бы применить while вместо вырожденного варианта for.
for(pmd0=m_pMeshUpdate; pmd0->next; pmd0=pmd0->next); // <=
pmd0->next = pmd;
Статический анализ, безусловно, нужен и полезен, но:
Внезапно, код может ревьювить не только руководитель и ревью масштабируется для любого количества людей (доказано Google).
Нет, я не против Code Review, но посчитайте сами, сколько времени понадобится руководителю, чтобы сделать обзор кода 10 человек? А на следующий день? А большего числа людей? В таких условиях Code Review необходим при изменении только ключевых компонентов продукта. В больших объёмах такой подход уже крайне неэффективен.
Внезапно, код может ревьювить не только руководитель и ревью масштабируется для любого количества людей (доказано Google).
Внезапно, код может ревьювить не только руководитель и ревью масштабируется для любого количества людей (доказано Google).
Под руководителями понимаются и ведущие разработчики какого-нибудь подразделения, их может быть достаточно много, но мой вывод всё равно актуален. А вообще я просто хотел оставить ссылки на 5 статей о проверке Google Chromium (1, 2, 3, 4, 5, ...,), так сказать, в качестве опровержения)
Ну так ревью ортогональны багам вообще-то, ревьювер не должен целенаправленно выискивать опечатки. Речь просто о том, что ревью нормально масштабируются на большие проекты и много людей. Но в силу ортогональности наличию багов это не имеет никакого значения в контексте статического анализа.
Просто Вы разделяете эти процессы. А когда общаешься с разработчиком, заведомо противником статического анализа, то в ход идёт единственный козырь — Code Review. Мой вывод основывается как раз на таких многочисленных прецедентах.
Да и не в опечатках дело, как Вам ошибка из раздела статьи «Code above has no bugs»? Чья ответственность?
Народ, я вот сам из мира JS со всеми этими новомодными баззвордами и тулзами и так далее. И мне вот не особо понятно — как в столь серьезном проекте, написанном явно не студентами (надеюсь), могут находиться столь примитивные ошибки, наподобие той что можно узреть в функции setActive, там где переменная сравнивается сама с собой?
Я у себя на проекте если пробел после запятой не поставлю, мне линтер из монитора в лицо плюнет и выдаст ошибку на весь экран вместо вебсайта. А уж задетектить сравнение переменной с самой собой, ну это же вообще детский сад, мне кажется все эти навороченные ИДЕ, которые грузятся пару лет, должны уметь делать такое по умолчанию (в то время как я сижу с Sublime Text и парочкой плагинов сверху, и весь линтинг динамически происходит там же не отходя от кассы).
В общем моя не понимать, как такой код попадает в продакшен (я уж молчу про тесты и все такое).
Я у себя на проекте если пробел после запятой не поставлю, мне линтер из монитора в лицо плюнет и выдаст ошибку на весь экран вместо вебсайта. А уж задетектить сравнение переменной с самой собой, ну это же вообще детский сад, мне кажется все эти навороченные ИДЕ, которые грузятся пару лет, должны уметь делать такое по умолчанию (в то время как я сижу с Sublime Text и парочкой плагинов сверху, и весь линтинг динамически происходит там же не отходя от кассы).
В общем моя не понимать, как такой код попадает в продакшен (я уж молчу про тесты и все такое).
могут находиться столь примитивные ошибки
Не соглашусь насчёт примитивных. Это они сейчас выглядят простыми и смешными, в дебрях кода это вполне себе потенциальные проблемы. Характер возникновения некоторых ошибок действительно примитивен.
Если Вы взгляните на наш обновляемый список статьей, то ещё больше ужаснётесь. Ошибки далеко не только прерогатива студентов, но и всех подряд в этой сфере.
навороченные ИДЕ, которые грузятся пару лет, должны уметь делать такое по умолчанию
Статический анализ прибавит ещё десяток лет к загрузке, поэтому эта ниша не для них, а для специальных инструментов. Современным IDE ещё шаблоны C++ разбирать учиться и учиться.
welcome to C++ world :)
предполагаю основная причина — анализатору плюсового кода «на лету» тяжело быть эфективным. Полноценный анализ возможен только при составлении AST, это фактически компиляция, и она занимает время, как пример — можно посмотреть на clang-плагин в QtCreator.
предполагаю основная причина — анализатору плюсового кода «на лету» тяжело быть эфективным. Полноценный анализ возможен только при составлении AST, это фактически компиляция, и она занимает время, как пример — можно посмотреть на clang-плагин в QtCreator.
Да, линтер C++ — довольно требовательная к ресурсам штука. Но не настолько, чтобы заметить какие-либо во время редактирования кода. По крайней мере, до тех пор, пока не начать редактировать заголовочные файлы. Есть и другие проблемы: экосистема C++ не имеет стандартизированного средства сборки проектов, менеджера зависимостей. Там до сих пор нет модулей! Проверять файл без учёта его зависимостей… ну это такое. Всё это усложняет процессы разработки, внедрения и пользования подобными ништяками.
Но, как я уже говорил, Clang делает успехи в этом направлении.
Но, как я уже говорил, Clang делает успехи в этом направлении.
Мне больше непонятно, как это прошло через компилятор. Как я вижу, используется clang-3.8. У меня он (
-Wall -Wextra) сходу ругается и на V547, и местами на V501. И многое другое, что в статьях про PVS говорится. А clang-4 покрывает чуть ли не половину перечисленного.Предположу, что слишком много шума (ложных срабатываний) у компиляторов, вот и не пользуются. Это когда рассматриваешь отдельные случаи, то все кажется просто и даже в выводе компилятора можно найти нужное. Но на практике всё это теряется в шуме бессмысленных предупреждений. Мы же очень много работаем не только над поиском многих паттернов ошибок, но и ещё очень много работаем над исключениями. Чтобы шума было меньше. Это ОЧЕНЬ важно.
Жесть, неужели проект такой большой, что такие конкретные и серьезные баги не проявляются на каждом шагу…
Реквестирую дайджест «самые интересные ошибки, найденные анализатором PVS-Studio в коде PVS-Studio». Скорее всего, он у вас в pre-commit/pre-push hooks, но тем не менее… :)
Ну например в "C# баги месяца" попало такое. :)
Магические числа с комментариями вместо именованных констан, ай-яй-яй!
У вас ругани на такое в диагностиках разве нет?
Ругаться на неименованные константы нельзя, кроме особых случаев. Вернее, ругаться можно на все константы, но как только в анализаторе появятся такие предупреждения, он превратится в тыкву.
Кстати, мы никогда не утверждали, что пишем идеальный код и у нас есть смелость сказать про это. Думаю, в этом есть польза. Польза конечно не том, что код не идеален, а в том, что признаем это. Благодаря этому у нас нет гордыни и мы спокойно используем различные методики для повышения качества и надежности кода (разные виды тестов, проверяем себя с помощью PVS-Studio, Clang и т.п.). Мы просто столько везде слышим пафосного, что вот мы то о-го-го и таких-то ошибок не совершаем. Вот только откуда же тогда вот эти 10893 ошибки… Никак инопланетяне по ночам в код их подмешивают. Впрочем, ничего нового, все мы считаем себя чуть лучше, чем есть средний программист.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Серьёзные ошибки в коде CryEngine V