Бестиарий программирования

Пример, как идеология педантичности стандарта MISRA C защищает от ошибок В C литерал 0 можно присваивать как численным типам, так и указателю (вместо NULL). Правило MISRA C 2012/2023 11.9, которое говорит, что нужно использовать именно NULL, может казаться избыточным. Например, здесь:

typedef struct  FT_Outline_
{
    short n_contours;        /* number of contours in glyph        */
    short n_points;          /* number of points in the glyph      */
 
    FT_Vector*  points;      /* the outline's points               */
    char*       tags;        /* the points flags                   */
    short*      contours;    /* the contour end points             */
 
    int flags;               /* outline masks                      */
} FT_Outline;
....
static const FT_Outline null_outline = { 0, 0, 0, 0, 0, 0 };

V2648 Use NULL macro instead of literal zero for pointers. Если заменить некоторые 0 на NULL никому лучше не станет. static const FT_Outline null_outline = { 0, 0, NULL, NULL, NULL, 0 }; Правило, кажется, просто украшательством стиля написания кода. Лишнее ограничение при написании кода... Какой практический прок? Давайте посмотрим, как такое предупреждение помогает выявить реальную ошибку.

typedef char FAR * FAR * png_charpp;
....
png_size_t
png_check_keyword(...., png_charpp new_key)
{
  ....
  if (key_len > 79)
  {
     png_warning(....);
     new_key[79] = '\0'; // <= V2648
     key_len = 79;
  }
  ....
}

Обратите внимание на тип переменной new_key – это указатель на указатель. Из-за опечатки, терминальный ноль обнуляет указатель, а не записывается в строку. Правильный вариант кода: (*new_key)[79] = '\0'; Благодаря осмотрительной педантичности найдена реальная ошибка. На самом деле, PVS-Studio и раньше эту ошибку находил с помощью другой диагностики – V527 It is odd that the '\0' value is assigned to 'char' type pointer. Но здесь именно хотелось продемонстрировать, как работают и помогают MISRA правила. Вообще ситуация, что один и тот-же баг выявляется разными детекторами, вполне частая ситуация и удивляться этому не стоит.   Почему я про MISRA вспомнил? Во-первых, мои коллеги сейчас занимаются подготовкой квалификационного пакета PVS-Studio согласно ГОСТ Р МЭК 61508 и ГОСТ Р ИСО 26262 по поддержке MISRA C:2012 и MISRA C:2023. Во-вторых, 23 сентября я буду с докладом "Анализатор PVS-Studio как средство достижения целей верификации ГОСТ Р ИСО 26262-6" на форуме "Безопасность транспортных средств". Приглашаю посетить мероприятие и мой доклад.

Сегодня у меня для любителей C++: Каждая идиома когда-то была проблемой.

Красивый и надёжный код почти никогда не рождается с первого раза. Сначала появляются ошибки, а уже потом – идиомы, которые помогают их избегать. На вебинаре рассмотрели реальные фрагменты кода из открытых проектов на языке C++, нашли в них проблемные места с помощью статического анализа, и разобрали более 10 идиом и паттернов, которые позволят защитить ваш код.

А для Java-разработчиков: 96-й подкаст Javaswag: Gradle, плагины для Minecraft и статический анализ в PVS-Studio.

Обсудили, как войти в Java через моды и серверы Minecraft, почему мир кубов живет на Netty и Gradle, как грамотно организовать мультимодульные проекты с помощью build-logic и type-safe accessor'ов, а также заглянули под капот разработки статических анализаторов кода (от поиска багов и Taint-анализа до соответствия ГОСТам).

Всем привет. Я уже делал цикл из 5 вебинаров про ГОСТ Р 71207—2024 (Статический анализ программного обеспечения): Общее описание и актуальность, Терминология, Критические ошибки, Технологии анализа кода, Процессы.   С тех времён я переосмыслил некоторые моменты. Прошли испытания статических анализаторов. Вышел ГОСТ Р 56939—2024 и так далее.   Поэтому меня посетила мысль вновь сделать обзор стандарта, но немного в другом формате: брать разные фрагменты из него и комментировать/обсуждать. Образно говоря, читать и разбирать ГОСТ вслух с интонацией, комментариями и отсылками :)   Это можно сделать по-разному:   1. Просто сесть и сделать записи. Потом это можно будет слушать как мини аудио-книгу/подкаст.   2. Сделать стрим, где попутно будут задаваться вопросы по разбираемому месту.   Второй вариант подразумевает, что это будет интересно аудитории и люди соберутся, иначе теряется смысл и проще пойти по первому пути. Решил сделать предварительный опрос.

Тяжело, когда ты программист и привык чётко воспринимать условия в повествовании :) Из описания конференции. Мы не делаем * Без воды и теории из интернета * Без курсов и инфоцыган * Не продаём и не рекламируем со сцены

Сегодня записи сразу двух вебинаров на тематику создания надёжных программных проектов. Автоматизация контроля качества и безопасности ПО

Вебинар посвящен тому, как встроить практики качества и безопасности в ежедневный цикл разработки. Эксперты PVS-Studio и Apsafe рассказали, почему статический анализ и автоматизированные проверки стали доступными инструментами для любой команды и как регулярный контроль безопасности помогает успевать за современным ритмом релизов без перестройки CI/CD.   Валерий Филатов (Developer Advocate, PVS-Studio) рассказал в своем докладе "Зачем платить за то, что уже работает?" о том что когда-то код-ревью, автотесты и CI/CD казались лишней бюрократией — дорогой и доступной немногим. Со временем выяснилось, что без них инциденты обходятся дороже, чем сама практика, а инструменты подтянулись настолько, что теперь это может себе позволить любая команда. На примере статического анализа посмотрели, почему Best Practices давно перестали быть недостижимым идеалом.   Виктор Тимашков (руководитель группы Apsafe) в своем докладе "Безопасность приложения это не разовая проверка, а ритм релиза" объяснил, что разовые пентесты и квартальные аудиты не успевают за поставкой: код уходит в прод чаще, чем его успевают «проверить снаружи». Разобрали, почему контроль должен повторяться вместе с релизом, что меняется в процессе разработки и как облачный контур (на примере Apsafe) встраивает проверки в этот ритм без перестройки CI/CD. 

Применение ЗОСРВ "Нейтрино" и PVS-Studio для разработки ПО согласно требованиям МЭК 61508

На вебинаре разобрали подходы к разработке функционально безопасного ПО для ЗОСРВ «Нейтрино» в соответствии с требованиями МЭК 61508 и показали, какую роль в этом процессе играют инструменты статического анализа.   В первой части поговорили о принципах разработки ПО для «Нейтрино», рассмотрели требования МЭК 61508 к инструментальным средствам, и продемонстрировали работу PVS-Studio в комплекте разработчика «Нейтрино».   Во второй части подробнее остановились на статическом анализе как инструменте для обеспечения безопасности. Разобрали требования МЭК 61508 и МЭК 26262, их связь со стандартами MISRA и рассмотрели, как PVS-Studio помогает контролировать качество и соответствие кода требованиям стандартов.   В завершение рассказали о новой мажорной версии PVS-Studio 8.0: рассмотрели ключевые изменения и нововведения релиза и обозначили дальнейшие направления развития инструмента, включая функциональную безопасность.

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

Однажды Эрнест Хемингуэй поспорил, что напишет самый короткий рассказ о том, как испортили Хабр. Вот он: OpenAI только что решили задачу тысячелетия и представили решение задачи Навье — Стокса Возможно OpenAI решили одну из задач тысячелетия: разбираемся в слухах вокруг уравнения Навье-Стокса Нейронный Навье-Стоксгейт: скандал с OpenAI вокруг решения «задачи тысячелетия» на $1'000'000 Или Хабр начнёт бороться с нейромусором, или умрёт :(

Уже завтра, 9 сентября в 12.00 вместе с партнерами PVS-Studio проведём вебинар: «Применение ЗОСРВ «Нейтрино» и PVS-Studio для разработки ПО согласно требованиям МЭК 61508» Разберём, как подходы к разработке ПО для ЗОСРВ «Нейтрино» соотносятся с требованиями МЭК 61508 и какую роль в обеспечении функциональной безопасности играет статический анализ. Наши партнёры представят обзор новой мажорной версии PVS-Studio 8.0 и дальнейшие направления развития. Поговорим не только о стандартах, но и покажем, как инструменты разработки и статического анализа работают вместе на практике. 👉 Подключайтесь к вебинару вместе с экспертами СВД ВС и PVS-Studio. 🔗 Регистрация: #Безопасная_разработка #Партнеры #Вебинары

Рассылка для С++ разработчиков на тему работы с legacy-кодом Команда YADRO предложила мне стать одним из авторов рассылки для С++ программистов, посвящённой работе с унаследованным кодом. C++ легаси — это же моё любимое! Естественно, я согласился. Рассылка начнётся с 15 сентября 2026, так что вот вам ссылка на лендинг и регистрацию: ~GHOST IN THE CODE(). Вас ждёт серия из 7 писем о том, какие инструменты и процессы помогают наладить работу с легаси-кодом. Их подготовят такие эксперты, как Антон Полухин, Константин Владимиров, Александр Иргер, Юлия Головчанская, Алексей Веселовский, Илья Шишков и я :) Помимо информации, обещают квесты от авторов. Ищите задачи в конце каждого письма и присылайте ответы на почту engineer@yadro.com. P.S. Кстати, на тему квизов. Напоминаю про наши спрятанные пасхалки в релизе PVS-Studio 8.00.

Рассылка для С++ разработчиков на тему работы с legacy-кодом Команда YADRO предложила мне стать одним из авторов рассылки для С++ программистов, посвящённой работе с унаследованным кодом. C++ легаси — это же моё любимое! Естественно, я согласился. Рассылка начнётся с 15 сентября 2026, так что вот вам ссылка на лендинг и регистрацию: ~GHOST IN THE CODE(). Вас ждёт серия из 7 писем о том, какие инструменты и процессы помогают наладить работу с легаси-кодом. Их подготовят такие эксперты, как Антон Полухин, Константин Владимиров, Александр Иргер, Юлия Головчанская, Алексей Веселовский, Илья Шишков и я :) Помимо информации, обещают квесты от авторов. Ищите задачи в конце каждого письма и присылайте ответы на почту engineer@yadro.com. P.S. Кстати, на тему квизов. Напоминаю про наши спрятанные пасхалки в релизе PVS-Studio 8.00.

Реинкарнация старой статьи: Сопротивляйтесь добавлению в проект новых библиотек — 10 лет спустя. Актуально, так как люди (а теперь и ИИ), тащат разное в проект, не думая, как потом это быстро аккуратно сопровождать, а уж тем более сертифицировать, если понадобится.

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

Настало время статей про баги в открытых проектах на TypeScript: Проверка исходников VSCode.

Подборка: 1) PVS-Studio 8.00: анализаторы JavaScript, TypeScript и Go, новые IDE плагины для WebStorm и GoLand (vk)

Вышел новый релиз PVS-Studio — 8.00. В нём: новые анализаторы для проектов на JavaScript, TypeScript и Go, новые IDE плагины для WebStorm и GoLand, расширение поддержки MISRA C++ 2023 и другие изменения. Подробнее о них рассказываем в видео!

2) Go-Go-Gadg...Error? Смотрим, как ошибаются Go разработчики! (vk)

В Go разработчики ошибаются как и в любом другом языке: опечатки, дубликаты, нерабочие условия проверок и тому подобное. Но почему? Ведь многие используют тот же go vet который прекрасно находит всё это… ведь так... да? На вебинаре разобрали частые и типовые ошибки Go разработчиков в известных проектах, а также узнали, какие ошибки не могут найти стандартные инструменты и подходы (и что с этим делать).

3) Агенты пишут код, а кто его проверяет? (vk)

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

4) Как разговорить человека и договориться (vk)

Small talk — это не просто короткая беседа, а способ устанавливать контакт, создавать доверие и открывать новые возможности для общения. На вебинаре разберём, как легко начинать и поддерживать такие разговоры, а также как использовать small talk в рабочих ситуациях — от нетворкинга и новых знакомств до сложных обсуждений, переговоров и договорённостей.

Я писал проект, довольно большой и столкнулся с проблемой, что со временем claude перестал вообще следить за корректностью кода и перешел к логике "главное что работает и тесты проходит". А то что константы напиханы в каждом файле, вместо выноса в отдельный модуль, похер ему было. В конце концов, при выполнении задач со временем все чаще начали появляться ситуации по примеру: "Да, я изменил, но в файле X был хардкод поэтому все сломалось" или "Все сломалось, тк при изменении модуля X он потянул за собой модуль Y, хотя они должны быть полностью независимы" Поддержка кода человеком прекратилась, так как код ИИ хоть и рабочий, но стал практически не поддерживаемым. Сам ИИ, спустя несколько месяцев признал, что пишет не поддерживаемый код только ради выполнения конечной задачи и прохождения тестов. В итоге, он сам перестал ориентироваться в нем и проект перестал работать. И проблема не в том что с нуля код у ИИ плохой. При каждодневных небольших изменениях накапливается хардкод, не нужные модули, нарушается DRY полностью. А исключить повторение и учесть все возможные связи становится просто невозможно, так как проект слишком большой и либо не помещается в контекст, либо начинается деградация качества. Так что использовании ИИ в крупных проектах без нормального ревью и человеческого фактора, в конце концов исключает работу человека полностью, а потом и сам ИИ перестает нормально работать. Самое опасное - что это очень долгий процесс и есть только два момента, когда можно повернуть назад - либо когда сам перестаешь ориентироваться в коде, либо когда все рушится. Что могу посоветовать - не полагайтесь на ИИ. Используйте его для ревью, проектирования архитектуры, документации или написания простого монотонного кода. Но все ключевые, уникальные и важные части проекта нужно исключительно делать вручную. P.S. это то, к чему я пришел примерно за полтора года использования ИИ. История длинная, но оставил самое важное

Пресс-релиз PVS-Studio 8.00: анализаторы для JavaScript, TypeScript и Go, плагины для WebStorm и GoLand и многое другое. Обратите внимание на раздел про поиск пасхалок в анализаторе :)

Анализаторы кода легко и быстро умеют находить множество ошибок, не очевидных с первого взгляда. Попробуйте посоревноваться с PVS-Studio в прозорливости! Мы сделали новые квизы для языков Go и JS/TS 🔥 Вас ждут 10 фрагментов кода, в которых наш анализатор нашёл ошибки. Все они взяты из известных Open Source проектов. Ваша задача — успеть найти ошибку за 60 секунд (не переживайте, фрагменты небольшие). Время посоревноваться с анализатором! А потом можно и его проверить 😉 - Найдите ошибки в JS & TS коде - Найдите ошибки в Go коде #квиз #js #ts #go

⚡️8, 9 и 11 сентября встречаемся на вебинарах 1️⃣ 8 сентября состоится второй вебинар серии "Надежность, качество, безопасность ПО: Методология и инструменты!" — "Автоматизация контроля качества и безопасности ПО". На примере статического анализа посмотрим, почему Best Practices давно перестали быть недостижимым идеалом. А также разберём, почему контроль должен повторяться вместе с релизом, что меняется в процессе разработки и как облачный контур (на примере Apsafe) встраивает проверки в этот ритм без перестройки CI/CD. 🗓 08.09 в 12:00 Регистрация по ссылке 🔗 2️⃣ 9 сентября приглашаем на вебинар "Применение ЗОСРВ "Нейтрино" и PVS-Studio для разработки ПО согласно требованиям МЭК 61508". На вебинаре разберем подходы к разработке функционально безопасного ПО для ЗОСРВ «Нейтрино» в соответствии с требованиями МЭК 61508 и покажем, какую роль в этом процессе играют инструменты статического анализа. 🗓 09.09 в 12:00 Регистрация по ссылке 🔗 3️⃣ 11 сентября будет вебинар "Каждая идиома когда-то была проблемой". Красивый и надёжный код почти никогда не рождается с первого раза. Сначала появляются ошибки, а уже потом – идиомы, которые помогают их избегать. На вебинаре рассмотрим реальные фрагменты кода из открытых проектов на языке C++, найдем в них проблемные места с помощью статического анализа, и разберём более 10 идиом и паттернов, которые позволят защитить ваш код. 🗓11.09 в 15:00 Регистрация по ссылке 🔗 Приглашайте коллег и приходите сами! Ждем вас! #вебинар #PVS_Studio