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

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

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

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

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

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

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

Я по роду своей деятельности много и часто медитирую над разнообразнейшим C++ кодом. И, как говорится, у меня накопилось. Не могу больше нести это в себе. Извините, сейчас и с вами поделюсь.

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

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

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

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

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

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

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

Это моя очередная заметка о том, как 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.

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

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

Ошибки мне нужны для создания нового уникального набора правил диагностики ошибок общего типа. Правил, которые действительно актуальны, которые найдут ошибки не в абстрактных приложениях, а в данных нам в ощущениях. Неинтересно уже искать в тексте завалявшиеся случайно триграфы. Ни разу не видел ошибку, связанную с триграфом. А вот опечаток, где для очистки строки вместо str.clear() написано str.empty(), полным-полно. Например, я писал про такой пример здесь. И ведь такие ошибки не находятся существующими инструментами! Поэтому мы и идем по пути создания нового, а не повторения старого.

Теперь попробую пояснить, про какие же ошибки мне хочется услышать и как.

У компилятора и сторонних инструментов статического анализа кода есть общая задача — выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.

В качестве испытуемого на этот раз выступит проект Notepad++ версии 5.8.2.

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

В компиляторе Visual Studio C++ имеется warning C4311 ('variable': pointer truncation from 'type' to 'type') предназначенный для выявления ошибок приведения указателя к 32-битным типам данных. В Intel C++ этому предупреждению соответствует warning #810. Пример обнаруживаемого дефекта:

void *ptr = x;
int y = (int)ptr;

В Win64 размер указателя стал 64-битным, а размер int остался по-прежнему 32 бита. Явное приведение типа обрежет значение указателя, что приведет к ошибке, если указатель ссылается на объект находящимся за пределами младших 4 Гбайт памяти (0x00000000FFFFFFFF).

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

Решил написать еще один небольшой пост в продолжение темы обзора сайта Intel Software Network (ISN). Хочется рассказать о некоторых статьях, которые можно найти на сайте ISN. Тема ориентирована на программистов или тех, кто планирует ими стать.