Люди, описывающие проектирования ПО как дисциплинированный процесс, тратят много энергии, заставляя всех нас почувствовать себя виноватыми. Мы никогда не станем достаточно структурированными или объектно-ориентированными для достижения нирваны при жизни. Все мы расплачиваемся за первородный грех – изучение Basic в особо впечатлительном возрасте. Но я готов спорить, что большинство из нас проектируют программы лучше, чем кажется пуристам.
Ф. Дж. Плоджер (P. J. Plauger)

Антипаттерн: неправильный способ определения переполнения, которое может возникать при сложении переменных типов unsigned short или переменных типов unsigned char.

При сложении двух переменных типов unsigned short, обе переменные приводятся к типу int. Результат сложения также будет иметь тип int. Поэтому, независимо от того, какие значения будут в переменных x и y, в результате их сложения переполнения никогда не возникнет.

Раньше была диагностика для C++, теперь добавили для C#: V3204.

Во имя эффективности – причём достигается она далеко не всегда – совершается больше компьютерных грехов, чем по любой другой причине, включая банальную глупость.
У.А. Вульф (W.A. Wulf)

Баг, найденный нами в своё время в MySQL. Программист для оптимизации вручную развернул цикл и допустил опечатку. Стоило ли оно того? С этой задачей вполне может справиться оптимизирующий компилятор.

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

Когда кто-то сказал "статистический анализ кода", то в 99% случаев он просто спутал название со "статический" :) Однако, понятие статистический анализ кода действительно есть и оно является одной из технологий, используемых статическими анализаторами кода.

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

Никто не умеет писать/проверять функции сравнения :) Даже разработчики LLVM. Сейчас полез с помощью PVS-Studio в код новой версии, а там: V501 There are identical sub-expressions to the left and to the right of the '&&' operator: bits2.is_nan() && bits2.is_nan() Compare.h 23

Парсим С++. 25 октября 12:00.
Приглашаю на бесплатный вебинар на тему разбору C++ кода. Коллега порассуждает о разных видах парсеров и о том, почему в случае С++ всё сложно.

На первые 90% кода приходится первые 90% времени разработки. На оставшиеся 10% кода приходятся другие 90% времени разработки.
Том Каргилл (Tom Cargill)

Слайд из доклада на Innovation Week. Если не брать Python, то анализатор PVS-Studio по-прежнему анализирует код, написанный на самых популярных языках C, C++, Java, C#. Будем продолжать углублять анализ в их направлении. Кстати, про новое: PVS-Studio 7.33: критические ошибки, пользовательские аннотации в C#, поддержка SN-DBS и многое другое.

Очередной баг из проекта LLVM. PVS-Studio выдаёт предупреждение: V522 Dereferencing of the null pointer 'target' might take place. LinalgTransformOps.cpp 2219

Перед нами случай когда анализатор выдаёт в каком-то смысле ложное предупреждение, но позволяет найти ошибку. Другими словами – это косвенное выявление ошибки.

Если условие if (!target) выполнится, то произойдёт разыменование нулевого указателя: target->getLoc(). Про это анализатор и выдал предупреждение. Но на самом деле, этот указатель никогда не будет нулевым. Однако не спешите делать вывод про недостижимый код.

Ошибка в том, что проверяется не тот указатель. Нужно проверять не target, а tilingOp. Опечатка.

Серьезным программистам я хочу сказать: уделяйте часть рабочего дня изучению и улучшению собственных методик. Хотя на программистов всегда давит какой-то бедующий или прошедший срок, методологическая абстракция – мудрая долговременная инвестиция.
Роберт У. Флойд (Robert W. Floyd)

Самая красивая ошибка, которую я нашёл с помощью PVS-Studio в 2024 году.

Образ разработчика, проектирующего программу рациональным безошибочным способом на основе ясно сформулированных требований, совершенно нереалистичен. Никакая система так никогда не разрабатывалась и, наверное, не будет разрабатываться. Даже примеры разработки небольших программ, встречающихся в учебниках, нереалистичны. Авторы перепроверяют и улучшают их до тех пор, пока не продемонстрируют нам то, что они хотели бы получить, а не то, что получилось на самом деле.
Дэвид Парнас и Пол Клементс (David Parnas and Paul Clements)

Выступил сегодня на SafeCode с докладом "Модельные варианты ошибок, или Как статические анализаторы находят ошибки, которые не могут искать". В открытом доступе запись появится позже, а пока решил поделиться презентацией.
P.S. Спасибо Андрею Кулешову

В моём докладе на SafeCode была юмористическая вставка на тему "опровержение великой теоремы Ферма с помощью оптимизирующего компилятора". Сегодня опубликована 8 часть путеводителя C++ программиста по неопределённому поведению. В ней можно прочитать про это подробнее.