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

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

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

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

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

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

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

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

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

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

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

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

Но вот насколько эта рекомендация актуальна в наше время? В стародавние времена, например, советовали не повторять вычисления. Считалось хорошим тоном вместо:

X = A + 10 + B;
Y = A + 10 + C;

написать так:

TMP = A + 10;
X = TMP + B;
Y = TMP + C;

Это моя очередная заметка о том, как PVS-Studio делает программы более надёжными. То есть где, и какие ошибки он обнаруживает. На этот раз под молоток попали примеры, демонстрирующие работу с библиотекой IPP 7.0 (Intel Performance Primitives Library). Хотел, вначале, этот пост поместить в блог Intel, но потом решил, что это будет совсем уже...

Я занимаюсь созданием анализатора PVS-Studio, выявляющего ошибки в исходном коде приложений на языке C/C++/C++0x. В связи с этим мне приходится просматривать большой объем исходного кода различных приложений, где с помощью PVS-Studio были обнаружены подозрительные участки кода. У меня накопилось достаточно примеров, в которых хорошо видно, когда ошибка появилась на свет из-за копирования участка кода и его модификации. Конечно, это не новая идея, что использовать Copy-Paste при программировании плохо. Однако попробуем не отделываться рекомендацией «не копируйте код» и подойдем к этой теме более внимательно.

К сожалению, нам придется сделать статический анализатор PVS-Studio 4.00 полностью платным. Мы планировали сделать платным только набор 64-битных правил, а анализ общего назначения и анализ OpenMP-программ свободными для использования. Но мир суров и не поддержал наши начинания.

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

В ходе обсуждения PVS-Studio 4.00 вновь встал вопрос, можно ли реализовывать большинство проверок, используя регулярные выражения, и не переусложняем ли мы, говоря, что обязательно необходимо строить и работать с деревом разбора. Вот пример комментария на эту тему. Подобный вопрос возникает уже не в первый раз, и я решил написать статью, чтобы объяснить, почему пытаться использовать регулярные выражения для анализа Си/Си++ кода — эта очень плохая идея.

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

Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной. Вы можете скачать PVS-Studio по адресу http://www.viva64.com/ru/pvs-studio-download/.

В статье кратко рассказывается о новых возможностях PVS-Studio. На примере статического анализа исходного кода проекта TortoiseSVN будет продемонстрировано использование новых диагностических возможностей.

Продолжу экскурсию по ошибкам в программах и демонстрацию полезности статического анализа кода.

Это мой последний пост про пока недоступную для скачиванию версию PVS-Studio. Планирую, что через неделю вы уже сможете попробовать первую beta-версию с новым набором правил общего назначения.

Рассмотрим два проекта. Первый — Fennec Media Project. Это универсальный медиа-плеер ориентированный на воспроизведение аудио и видео в высоком разрешении. В комплект исходных кодов входит множество модулей расширения (plugins) и кодеков, но анализироваться будет только сам плеер. Исходный код последней на данный момент версии 1.2 Alpha доступен здесь.

Второй проект — qutIM. Это кроссплатформенный клиент мгновенного обмена сообщениями с открытым исходным кодом. Был проанализирован код на момент начала ноября 2010 года. Набор исходных кодов был предоставлен мне одним из разработчиков, но вы также можете скачать исходный код с официального сайта. Этот разработчик, кстати, присутствует здесь — gorthauer87.

Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам — WinMerge.

В последнее время в сети возникает довольно много тем вокруг стартапов вообще и конкретно проектов, которые создаются или созданы за пару дней, за выходные, за неделю. На мой взгляд, это довольно странная активность, так как все CD-Ejector давно созданы, а их авторы уже заработали свои миллионы. Или нет?

<< Читать первую часть статьи

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

Читатели наших статей, посвященных разработке 64-битных приложений, часто упрекают нас в отсутствии обоснованности описываемых проблем. А именно, что мы не приводим примеры ошибок в реальных приложениях.

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

Продолжение статьи >>

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

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

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