1 апреля 2024 года введён в действие новый ГОСТ Р 71207–2024 "Статический анализ программного обеспечения". Если в ГОСТ Р 56939–2016 говорится о необходимости использования статического анализа при разработке безопасного программного обеспечения (РБПО), то ГОСТ Р 71207–2024 уточняет, что именно это означает.
Информация в ГОСТ очень плотная, и её тяжело сразу воспринять, если вы ранее не имели дело со статическим анализом кода и РБПО. Поэтому я подготовил и провёл цикл из 5 вебинаров, где разобрал различные аспекты ГОСТ и примерами пояснил некоторых термины.

Мы учим анализатор PVS-Studio искать не только универсальные ошибки, но и связанные с использованием распространённых библиотек. Например, в рамках поддержки из GameDev индустрии, мы реализуем специализированные диагностики для Unity и Unreal Engine.

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

Тем не менее, определённый выигрыш можно получить. Пример такой диагностики V4006. Помогает сократить количество математических операций, выполняемых над матрицами, векторами и т.д.

Если заинтересовались попробовать PVS-Studio, то промокод progtales позволяет получить триальную версию сразу на месяц.

Доклад "Разрушители мифов: С++ уже не торт" от Филиппа Хандельянца (тимлид C++ команды PVS-Studio). Язык программирования С++ существует уже больше 40 лет. За это время появилась целая куча мифов и небылиц о нём. Действительно ли С++ непрост для новичков? С++ устарел и больше никому не нужен?

Добавил комментарии. Прошу написать что-то доброе для тестирования.

Прошли экватор, выложив 6 из 11 частей книги "Путеводитель C++ программиста по неопределённому поведению". Очень много букв, так что не стоит ждать все части. Приглашаю читать первые шесть :)

Часть 1, Часть 2, Часть 3, Часть 4, Часть 5, Часть 6.

Пока под рукой тетрадка с конспектами, хочется похвалиться как у нас в компании построен процесс адаптации новых сотрудников. Сейчас поймёте взаимосвязь :)

К сожалению, у многих компаний нет плана как обучать новых людей и понимая какую информацию давать. Сам проходил через подобное. Спрашиваешь: с чего начать, что почитать, куда и что посмотреть? Ой. Ну вот по коду можешь пока побродить. Ах да, у нас же поверхности в CAD-системе и нужно знать математику, связанную с ними – читай про NURBS. Сижу, читаю про NURBS (неоднородные рациональные B-сплайны для представления кривых и поверхностей). Конспектирую, что-то перевожу... На фотке как раз мои потуги осознать...

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

У нас в PVS-Studio есть план (чеклист) введения человека в должность, который создаёт HR для себя и руководителя. Там начиная от знакомства с пожарной безопасностью и оформления в отделе кадров, и закачивания решением по итогам испытательного срока. Человек порционно получает информацию в специальной рассылки из 10 писем: структура компании, что такое один-на-один и так далее.

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

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

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

P.S. Здорово, что получилось всё так организовать. Надо не забыть текстом с HR командой поделиться :) Думаю им приятно будет.

Коллега профессионально набросил на тему, медленнее ли С++ std::array классических C массивов или нет. Читайте, изучайте графики, рассказывайте автору в комментариях почему он не прав и что не ту линейку прикладывал :)

Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям.
Мартин Фаулер (Martin Fowler)

Юбилейный баг. Он станет 16000-ым в коллекции багов, которую мы пополняем в процессе проверки открытых проектов для написания статей. Найден в проекте DPDK, про который я скоро напишу пару публикаций.

Ещё это значит, что благодаря нашей команде, в открытых проектах станет на 16000 ошибок меньше.

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

Неделю ничего не писал – отдыхал перед началом сезона конференций и вебинаров и т.д. И раз уж речь зашла про мероприятия, предлагаю вниманию мою сегодняшнюю заметку: SafeCode – конференция, которой мне не хватало.

И заодно недавно опубликованный подкаст с мои участием.

Неформальные процедуры обзоров передавались от человека человеку в общей культуре программирования задолго до того, как информация об этом стала появляться в печатных материалах. Необходимость обзоров была настолько очевидна лучшим программистам, что они редко упоминали об этом в статьях и книгах, тогда как худшие программисты считали, что они настолько хороши, что их работа не нуждается в обзорах.
Дениел Фридмен и Джеральд Вайнеберг (Daniel Freedman and Gerald Weinberg)

Никто не застрахован от простейших ошибок. Перед вами фрагмент кода из одного из самых качественных проектов – LLVM. А ошибка дурацкая: если дошло до вычисления правого операнда ИЛИ, то указатель равен nullptr и он смело разыменовывается. Кстати, наверное в среду как раз проект LLVM возьму для демонстрации работы PVS-Studio на вебинаре УЦ Маском.

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