Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
> ошибки формата printf
о_О
о_О
Не верится как-то, что ошибки ввода/вывода — аж на втором (!) месте. Скорее, анализаторам их проще находить, вот и все.
В квейке то!?
sprintf, ваш КО
Зря удивляетесь. Допустим ситуацию:
есть некая переменная long, после рефакторинга ее тип поменяли на unsigned long,
а спецификатор в printf поменять забыли.
Поверьте это не трудно.
ПС: пример немного отдает синтетикой, но все же.
есть некая переменная long, после рефакторинга ее тип поменяли на unsigned long,
а спецификатор в printf поменять забыли.
Поверьте это не трудно.
ПС: пример немного отдает синтетикой, но все же.
новая степень падения — ализар опустился до заказных рекламных постов…
Разработчикам PVS фартануло — Кармак упомянул их продукт
Да, приятно под новый год получить такой подарок! Но чтобы «фартануло» мы столько усилий приложили. Реализовывали пожелания, прикрутили Clang для скорости, писали статьи. Так что скорее приятно ощутить, что делается всё это не зря и приносит пользу. Везения тут 1%.
А вы своей PVS проверяли код PVS?
Мне было бы интересно, что PVS скажет о интерпретаторе Ruby. Может вам будет в будущем тоже будет интересно протестировать его.
Да, это точно, чтобы повезло, надо очень много усилий приложить перед этим. Правда, обычно этого не видят окружающие, думая, что «просто повезло».
Кстати, по поводу скорости работы: Советы по повышению скорости работы PVS-Studio.
сотрудничество с компанией Armadillo Aerospace позволило ему познакомиться с совершенно иным миром разработки ПО, где безопасность является критическим фактором.
Тут некорректно говорить о сотрудничестве, ведь он является основателем этой компании.
Активные обсуждения этой статьи (en):
- Reddit: John Carmack on Static Code Analysis
- Hacker News: John Carmack on the importance of Static Code Analysis
В одном из каментов пишут что SQLite отказался от static code analysis в пользу тестов и имеют 1000:1 покрытие. И типа у них все пучком.
Интерестно былобы чтоб PVS прогнали SQLite на предмет багов.
Интерестно былобы чтоб PVS прогнали SQLite на предмет багов.
Вот честно, не знаю, проверяли или нет. Есть два варианта.
Вариант первый. Проект проверяли, но я про это забыл. Как я понимаю, проект маленький и мы могли в нем ничего не найти. Тогда факт его проверки выпал из головы.
Вариант второй. Мы не проверяли этот проект.
Покопался у себя в почте и записях. Нашел только вот это:
…
Нашел в SQLite3 следующий шедевр (встречается не раз)
//azCol имеет тип char*
int len = strlen(azCol? azCol: "");
Это лютый бешеный песец. Вызов strlen() (наверняка не встраивается) вместо того, чтобы написать 0 в коде. Должно было быть так:
int len = azCol? strlen(azCol): 0;
Полагаю, выявлять этот песец автоматом не сложно.
…
Это предложение на тему правил по оптимизации. Кстати, возможно этот человек проверял SQLite с помощью PVS-Studio и теперь нам уже там искать нечего… :)
Вариант первый. Проект проверяли, но я про это забыл. Как я понимаю, проект маленький и мы могли в нем ничего не найти. Тогда факт его проверки выпал из головы.
Вариант второй. Мы не проверяли этот проект.
Покопался у себя в почте и записях. Нашел только вот это:
…
Нашел в SQLite3 следующий шедевр (встречается не раз)
//azCol имеет тип char*
int len = strlen(azCol? azCol: "");
Это лютый бешеный песец. Вызов strlen() (наверняка не встраивается) вместо того, чтобы написать 0 в коде. Должно было быть так:
int len = azCol? strlen(azCol): 0;
Полагаю, выявлять этот песец автоматом не сложно.
…
Это предложение на тему правил по оптимизации. Кстати, возможно этот человек проверял SQLite с помощью PVS-Studio и теперь нам уже там искать нечего… :)
Тесты выглядят как более дорогая вещь, статическая проверка какбе ничего не стоит разработчику, то есть не требуется писать какой-то дополнительный код в проект. В некоторых случаях очень сложно организовать покрытие тестами кода, который например отвечат за user interface/графику/сетевое взаимодействие/итд. Если у вас библиотека которой пользуются много пользователей есть время и смысл обложить ее всю тестами вдоль и поперек, а когда у вас реальный проект со сроками не совсем понятно зачем отказываться от статического анализа.
А вы как думали. Они наверное про консольный квейк. Представьте себе вы в консоли ввели
«move left; realgun; zoom 4; bum»
а тут у вас оказывается printf в игре заглючил, и все. смерть пришла
«move left; realgun; zoom 4; bum»
а тут у вас оказывается printf в игре заглючил, и все. смерть пришла
за поправку спасибо. но сути не меняется. главное с этим инструментом
zoom 4
А я скучаю за теми вренами когда игры делали для души. Сейчас игра мечны у продюсеров воспринимается как какое-то говнище. И слова им не скажи по поводу «мечты».
Но большинство идей современных игр придумано тогда: TTD, CIV,KB, KB2, DOOM — этот список можно дополнять сколько угодно. И играть было совсем не «бр...», благо тогда еще жены небыло и никто не ограничивал тебя по времени проведенному за игрой :-)
zoom 4
А я скучаю за теми вренами когда игры делали для души. Сейчас игра мечны у продюсеров воспринимается как какое-то говнище. И слова им не скажи по поводу «мечты».
Но большинство идей современных игр придумано тогда: TTD, CIV,KB, KB2, DOOM — этот список можно дополнять сколько угодно. И играть было совсем не «бр...», благо тогда еще жены небыло и никто не ограничивал тебя по времени проведенному за игрой :-)
Как ни крути, получится MUD или Rogue-like :)
Консоль в квейке очень даже активно использовалась. Редкий более-менее хороший игрок не прописывал себе в конфиг хотя-бы пару элементарных скриптов. Часто использовались скрипты для рокет-джампов (без направления, просто 2 кнопки одновременно), разных курсоров и сенсы для разного оружия, алерты команде с указанием местоположения, сообщение в виде текущего здоровья (когда одного убили, а у другого 1hp остался использовали) итд.
Еще через консоль часто сервером управляли (голосовалки всякие, таймауты) и над ним-же издевались (g_gravity 0.1 итд). В общем, очень unixway игра была. В современной реинкарнации q3 такого уже не замечается.
Еще через консоль часто сервером управляли (голосовалки всякие, таймауты) и над ним-же издевались (g_gravity 0.1 итд). В общем, очень unixway игра была. В современной реинкарнации q3 такого уже не замечается.
Надо подкинуть идею Шахиджаняну.
mplayer some_video.avi # наберём в консоли unix?
> когда десятки программистов находятся в условиях нехватки времени
Такого рода проблемы генерируют большее количество ошибок, и особенно стратегических упущенний, чем может осилить статистический анализ кода. Поэтому статистический анализ эффективен только в условиях грамотного управления проектом
Такого рода проблемы генерируют большее количество ошибок, и особенно стратегических упущенний, чем может осилить статистический анализ кода. Поэтому статистический анализ эффективен только в условиях грамотного управления проектом
Это на BBM автотекст при вводе «помог» (
Из вашей статьи пропал вывод Кармака:
Если ваша версия Visual Studio включает /analyze, используйте его. В противном случае попробуйте PVS-Studio, возможно имеет смысл купить его.
Если ваша версия Visual Studio включает /analyze, используйте его. В противном случае попробуйте PVS-Studio, возможно имеет смысл купить его.
На примере PC версии Rage видно, как замечательно работает его метод.
вы играли квейк? это наверное один с самых стабильных игр ever. Можете Джону про TDD рассказать и свой код показать. Он посмеется. Вот тогда гуляй, рванина.
Русский не родной, так что поправляйте по делу или не подёбывайте.
Проектирования и читабельность — субьективные понятия. Никто не будет покупать вашу программу или игру, если там будет изящнейшая архитектура или идеальное форматирование согласно GNU стилю отступов. Но это чепуха.
Куда-то вы от TDD увиливаете. Все, что я знаю о вашем коде, это то, что вы его _возможно_ пишите по методологии сначала тест, потом код. И это если бы Джон использовал этот подход при создании квейка, то никакого квейка бы не было.
На счет возраста даже отвечать вам не буду.
Проектирования и читабельность — субьективные понятия. Никто не будет покупать вашу программу или игру, если там будет изящнейшая архитектура или идеальное форматирование согласно GNU стилю отступов. Но это чепуха.
Куда-то вы от TDD увиливаете. Все, что я знаю о вашем коде, это то, что вы его _возможно_ пишите по методологии сначала тест, потом код. И это если бы Джон использовал этот подход при создании квейка, то никакого квейка бы не было.
На счет возраста даже отвечать вам не буду.
Т.е. по мнению Джона важен именно результат который выполняет код, а не то как он при этом выглядит… Ну да — для игрушки которая в принципе должна быть интересной периодически возникающие баги (речь о минорных багах. Крэши просто выводят из себя особенно если не вовремя возникают) не столь важны как интересный геймплей. Однако программы могут нести не только игровые но и обучающие, рабочие функции где возникновение бага может очень дорого стоить.
Забавно, что был упомянут статический анализ кода, парное программирование, но не было упомянуто юнит тестирование и банальное «коде ревью» — это же более простые и дешевые способы существенно повысить качество кода.
Забавно, что был упомянут статический анализ кода, парное программирование, но не было упомянуто юнит тестирование и банальное «коде ревью» — это же более простые и дешевые способы существенно повысить качество кода.
Юнит тестирование и банальное «коде ревью» — это далеко не простые и далеко не дешевые способы повысить качество кода. Варианты «для галочки» — не в счёт. Я имею в виду, когда тестами покрыто 50% кода, а кодк ревью, это когда раз в неделю начальник просматривает код нового студента.
Однако — так уж получается, что в средней по уровню команде (в которой обычно есть студенты тоже) наиболее болезненные баги получаются именно из-за не правильного подхода к решению задач ( подхода к реализации, подхода к багфиксу) — т.е. просто из-за кривых рук.
А реализация юнит тестов хотя-бы на высоком уровне (20%) позволит вовремя заметить не менее серъезные ошибки.
Но трудные логические ошибки, которые глаз не видит или просто сотню мест (номера строк) где забыли проинициализировать переменные — конечно лучше увидит анализатор.
Поэтому использовать оный лучше при рефакторинге (либо просто оптимизации) кода или при возникновении багов, сценарий воспроизведения которых не постоянен.
А реализация юнит тестов хотя-бы на высоком уровне (20%) позволит вовремя заметить не менее серъезные ошибки.
Но трудные логические ошибки, которые глаз не видит или просто сотню мест (номера строк) где забыли проинициализировать переменные — конечно лучше увидит анализатор.
Поэтому использовать оный лучше при рефакторинге (либо просто оптимизации) кода или при возникновении багов, сценарий воспроизведения которых не постоянен.
Полный перевод статьи: Статический анализ кода. А оригинал теперь доступен здесь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Джон Кармак о статическом анализе кода