Это уже четвертая заметка, где я хочу поделиться полезными наблюдениями о паттернах ошибок и том, как можно с ними бороться. В этот раз я затрону такую тему, как обработка редких и аварийных ситуаций в программах. Рассматривая множество программ, я пришел к выводу, что код обработки ошибок в Си/Си++ программах — одно из самых ненадежных мест.
К чему приводят такие дефекты? Программа, вместо того, чтобы выдать сообщение «файл X не найден», падает и заставляет пользователя гадать, что он не так делает. Программа для работы с базой данных выводит невразумительное сообщение, вместо того, чтобы сообщить, что неверно заполнено одно из полей. Попробуем сразиться с этой разновидностью ошибок, которые досаждают нашим пользователям.

Компания Intel проводит множество программ, связанных с обучением, организует конкурсы по программированию, приглашает на встречи и бесплатные конференции. К сожалению, часто это проходит мимо, и человек, случайно потом, узнав про уже завершившееся мероприятие, огорчается, что не принял в нём участие. Кстати, участие в конкурсах Intel часто приводит к тому, что и сам участник потом оказывается в Intel. Уже пару раз сам наблюдал такую картину. На одной встрече человек приехал за призом, а на следующий год — раз, и уже сам с бейджиком «Сотрудник Intel». Так что имейте в виду. :)

Однако, чтобы получить внимание со стороны Intel, необязательно сражаться на олимпиадах, есть и другие интересные и полезные пути. Например, можно стать участником сообщества Intel Software Network (ISN) и автоматически начать участие в конкурсе «Мастер программирования». Именно про эту программу я и хотел немного рассказать.

Компания id Software имеет лицензию на PVS-Studio. Тем не менее, мы решили проверить исходные коды Doom 3, которые недавно были выложены в сеть. Результат — ошибок найдено мало, но всё-таки найдено. Я предполагаю, что это можно объяснить так.

Часть кода Doom3 используется и сейчас и, наверное, там ошибки уже исправлены. Часть кода устарела и не используется. Скорее всего, именно там и найдены подозрительные участки кода.

Для тех, кто интересуется данной тематикой, предлагаю вниманию фрагменты кода, на которые указал анализатор PVS-Studio. Как всегда напоминаю, что рассматриваю только некоторые предупреждения. Другие участки проекта требуют знания структуры программы, и я их не изучал.

Общаясь с людьми на форумах, я заметил несколько стойких заблуждений, касающихся методологии статического анализа. Я хочу развеять следующие мифы:

1. Статический анализатор это продукт разового применения.
2. Профессиональные разработчики не допускают глупых ошибок.
3. Динамический анализ лучше чем статический.
4. Программисты хотят добавлять свои правила в статический анализатор.

Заметка обращается к предпринимателям, которые пользуются услугами SEO-шников. И смысл её простой — не ленитесь посмотреть, что они делают и как продвигают продукцию. И чуть что — гоните их в шею. Бог с тем, что они замусорили весь интернет. Есть большая вероятность, что для вашего бизнеса от них столько же вреда, сколько и пользы. Пустая трата денег.

Не секрет, что для продвижения сайтов используется такая технология, как «рерайт». Смысл в том, чтобы получить «уникальный» текст, основываясь на других текстах. Беда в том, что занимаются этим люди, которые не только не разбираются в тематике, но и которым вообще абсолютно всё равно на результат их работы.

А ведь вам, уважаемые предприниматели, не всё равно? Если нет, то попробуйте поискать свою продукцию в интернете. Возможно, вы узнаете о ней много интересного. И тогда интернет станет чуточку лучше. А чтоб простимулировать внимательность, я опишу забавную ситуацию.

Прогресс не стоит на месте. Развивается и мой любимый статический анализатор кода PVS-Studio. И недавно я понял, что те проекты, которые мы уже проверяли, можно вполне проверять заново. Писать про это новые статьи как-то странно и вряд ли они получатся интересными. Однако одну такую статью я всё-таки думаю надо сделать. Она станет еще одним аргументом в пользу утверждения, что настоящую пользу от статического анализа можно получить только при его регулярном использовании, а не при проверках от случая к случаю. Итак, посмотрим, что же удалось найти нового интересного в проекте Intel IPP Samples.

Проверив код ReactOS, я смог исполнить сразу три своих желания. Во-первых, давно хотелось написать статью об обыкновенном проекте. Не интересно проверять код таких проектов, как Chromium. Он слишком качественен и, на поддержание этого качества тратятся ресурсы, недоступные в обыкновенных проектах. Во-вторых, появился хороший пример, на котором можно показать, как необходим статический анализ в большом проекте, особенно если он разрабатывается разнородным распределенным коллективом. В-третьих, я получил подтверждение, что PVS-Studio становится всё лучше и полезнее.

Мы случайно проверили проект Clang. Думаю, результат будет любопытен ряду разработчиков. Подробности под катом.

В последнее время, рассказывая о проверке очередного проекта, я всё время повторял, что это очень качественный код и ошибок в нём практически не найдено. Примером может служить анализ таких проектов, как Apache, MySQL, Chromium. Почему мы выбираем такие приложения, я думаю понятно. Про них всех знают и никому не интересно, какие ужасы можно найти в дипломной работе студента Васи. Однако иногда мы поверяем и те проекты, которые просто случайно попали под руку. Некоторые такие проекты оставляют тяжёлые впечатления в моей тонкой и ранимой душе. В этот раз мы проверили Intel® Energy Checker SDK (IEC SDK).

В этот раз с помощью PVS-Studio мы проверили Apache HTTP Server. Как и ожидалось, нашли в нём ошибки. Ошибок мало. Это тоже ожидаемо.

С этой же ситуацией сталкиваются и другие разработчики, испытывая PVS-Studio на своих проектах. К сожалению, первый вывод, который хочется сделать, увидев только несколько ошибок, что такой инструмент ему малополезен. Сейчас я придумал хорошую аналогию, которая поясняет, почему это не так.

Это третья статья, где я хочу рассказать про новую пару приёмов при программировании, которые помогут сделать код более простым и надежным. С предыдущими двумя заметками можно познакомиться здесь [1] и здесь [2]. В этот раз примеры будут взяты из проекта Qt.

В PVS-Studio появился режим работы, который поможет максимально рано выявлять ошибки и опечатки. Анализатор запускается сразу после компиляции файлов и если что-то не так, покраснеет от стыда за ваш код. Фича доступна на данный момент только для пользователей Visual Studio 2010.

В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium — один из лучших проектов, который мы проверяли с помощью PVS-Studio.

По интернету ходят невнятные слухи о неком WinC++. Толи это просто новое название Visual C++, толи нечто большее. Поскольку я заинтересован и озабочен тематикой Visual C++, то проявил к этой теме внимание. Мне попалась свежая статья от 4 мая «What is WinC++ and how does it figure in Microsoft's bid to make tools a $2 billion business?». Поскольку на русском языке пока про WinC++ тихо, я решил предложить Хабра-сообществу перевод этой статьи. Признаюсь, перевод вышел не очень, читается скучно. Поэтому многие, наверное, предпочтут познакомиться с оригиналом.

Прошу меня за эту статью не журить, как говорится первый блин комом. Полезное и главное в этой статье, пожалуй, то, что Microsoft явно не планирует хоронить Visual C++, а наоборот влить в это направление новые силы. На Си++ смотрят как на живой и развивающийся инструмент. Это радует (меня, по крайней мере :)).

Итак, собственно перевод статьи Мэри-Джо Фолли: Что такое WinC++ и как она связана со стремлением Microsoft поднять оборот продаж инструментов до 2 миллиардов долларов?

На конференции ADD 2011 я выступал с докладом «Статический анализ Си++ кода». Благодаря старанию Стаса Фомина belonesox появился замечательный скринкаст (видео + презентация), который я предлагаю вашему вниманию.

В докладе показано много примеров интересных ошибок, найденных мною в open source проектах. Я расскажу, как можно найти многие подобные ошибки еще на этапе написания кода с помощью методологии статического анализа.

Неоднократно замечал нездоровый диссонанс, когда кто-то в комментариях к статье на Хабрахабр использует фразу «а вот хорошо бы...» или схожую с ней. Обычно на это следует раздраженный ответ автора. Комментатор делает обиженное лицо, ставит минус за ответ ему и ещё жалуется сообществу «я-то хочу как лучше, а мне тут...».

Я сам как автор множества статей не раз попадал в эту ситуацию. И регулярно замечаю её в других топиках. Хочу немного разобраться с этой ситуацией.

КПД российских IT-конференций крайне низкий. Можно сказать вообще никакой. В первую очередь он низкий для докладчиков и спонсоров. Но и простые слушатели мало используют возможности конференций и упускают уникальные возможности по общению.

Пожалуй, первыми, кто заметил эту проблему, являются организаторы ADD 2011. Я ещё полон впечатлений от участия в ней, и хочу написать, почему хабраюзерам стоить заглянуть на следующую ADD.

Многие могут счесть спор, о том, что лучше пробелы или табуляции в коде за holy wars. Однако нет, я не хочу устраивать дискуссию на эту тему. Я однозначно утверждаю, что в обязательном порядке следует использовать пробелы. И разговор и «предпочтении того или иного» здесь не уместен. Как не уместно в наше время обсуждать, что удобнее, компьютер или печатная машинка. Поскольку печатные машинки закончили свое существование, ориентироваться в дальнейшем на их использование, по меньшей мере, нерационально. А если ещё учесть, сколь удобнее пользоваться компьютером для набора текста, то вопрос выбора просто отпадает.

С пробелами и табуляцией ситуация не настолько грандиозна и масштабна, но аналогия прослеживается. Далее я поясню, почему рационально перейти на пробелы для форматирования кода.

Это вторая статья о том, как можно избежать ряда ошибок еще на этапе написания кода. В предыдущей заметке уже упоминался совет избегать множества вычислений в одном выражении. Однако, этот вопрос требует более пристального внимания. Рассмотрим опасность сложных условий, и как можно предупредить многие логические ошибки.

Я добрался до кода широко известного клиента мгновенных сообщений Miranda IM. Вместе с различными плагинами это достаточно большой проект, размер которого составляет около 950 тысяч строк кода на C и C++. И, как в любом солидном проекте с историей развития, в нем имеется немалое количество ошибок и опечаток.

Рассматривая дефекты в различных приложениях, я заметил некоторые закономерности. И сейчас на примере дефектов, найденных в Miranda IM, я попробую сформулировать некоторые рекомендации, которые позволят избежать многих ошибок и опечаток ещё на этапе написания кода.