Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?
Директор по маркетингу
С++: освобождение ресурсов в деструкторах с использованием вспомогательных функций
В этой статье мы рассмотрим, как правильно разрушать объекты в ООП программе на языке C++, не выполняя избыточных операций. Этим мы завершим цикл публикаций, посвящённый обзору ошибок в игровом движке qdEngine.
Проверка игрового движка qdEngine, часть третья: дополнительная десятка багов
В первой статье про qdEngine было рассмотрено 10 ошибок, выбранных плагином PVS-Studio. Однако есть ещё 10 багов, заслуживающих внимания. Как говорится, лучше учиться на чужих ошибках. Заодно они хорошо демонстрируют возможности PVS-Studio в выявлении разнообразнейших ошибочных паттернов.
Проверка игрового движка qdEngine, часть вторая: упрощение C++ кода
В этой статье мы рассмотрим, как статический анализатор PVS-Studio воодушевляет заняться рефакторингом кода. Ведь чем короче, проще и понятнее код, тем меньше в нём ошибок.
Проверка игрового движка qdEngine, часть первая: топ 10 предупреждений PVS-Studio
Баги, которые удалось найти в движке qdEngine, оказались весьма разнообразны, поэтому не хочется мешать всё в кучу в одной публикации. Читатели могут упустить интересные темы, связанные с написанием качественного кода. Поэтому разбор проекта выйдет в виде серии публикаций, первая из которых посвящается наиболее интересным срабатываниям с точки зрения плагина PVS-Studio.
Статический анализатор подталкивает писать чистый код
Статические анализаторы помогают не только обнаруживать ошибки и дефекты безопасности, но и делать код чище. Выявляя лишние проверки, дублирующие действия и другие аномалии, можно сделать код проще, красивее и легче для чтения. Разберём это на практическом примере рефакторинга функции.
Встречи с командой PVS-Studio, митапы, сотрудничество
Команда PVS-Studio в целом и я в частности активно участвуем в различных конференциях, подкастах, митапах и других мероприятиях. Нового в этом нет, но есть пара причин сделать маленькую заметку на эту тему.
Первая причина — предложить тем, кто интересуется нашим блогом на Хабре, подписаться на рассылку/телеграм/группу, чтобы не пропустить мероприятие, где можно пообщаться с нами. Живое общение — это всегда интересно.
Вторая причина — ещё раз озвучить, что мы открыты к сотрудничеству и готовы пообщаться с организаторами митапов, DevRel-ами компаний и т.д. Напишите нам.
Притча о нулевом указателе для ленивых C программистов
Я согласен, что ошибка выделения памяти с помощью malloc редкая ситуация, и после такой ошибки, скорее всего, невозможно полноценное функционирование программы. Но меня удивляет, с каким упорством программисты, приводя эти аргументы, предлагают вообще ничего не делать в такой ситуации. Я не призываю всех делать сложные механизмы восстановления работы после нехватки памяти или использовать заранее выделенные резервные буферы. Многим программам не нужны такие сложные механизмы. Тем не менее я не понимаю, почему хотя бы минимально не обработать такие ситуации корректно. Раз других объяснений пока не хватило, попробую в этот раз рассказать короткую притчу.
Почему проверять результат вызова malloc c помощью assert плохая идея
Указатель, который вернула функция malloc, необходимо проверить перед использованием. Неправильным решением будет использовать для этого макрос assert. В этой статье мы разберём, почему это является антипаттерном.
Следует ли проверять указатель на NULL перед вызовом функции free?
Короткий ответ: нет. Тем не менее, раз про это вновь и вновь спрашивают на Reddit, Stack Overflow и других сайтах, пришло время подробно разобрать эту тему. Оказывается, есть много интересного, о чём можно порассуждать.
Какую статью хочется прочитать в нашем блоге на тему C++, C# или Java?
Наша команда регулярно публикует теоретические статьи, пишет про поиск ошибок в открытых проектах, делает развлекательные посты. В общем, в нашем блоге много всего интересного и полезного. Однако не ходим ли мы по кругу с одними и теми же темами? Нам сложно взглянуть на нашу ленту публикаций со стороны. Приглашаем поделиться идеями, какие статьи хотелось бы видеть от нашей команды.
На данный момент контент нашего блога можно разделить на 4 основные категории:
- Теоретические статьи;
- Информационно-развлекательные статьи;
- Проверка открытых проектов;
- Всё остальное.
Опечатки, нулевые указатели и коварный таб: 33 фрагмента в библиотеке GTK
GTK – популярный фреймворк с открытым исходным кодом для создания графических интерфейсов, который интересно проверять с помощью анализатора PVS-Studio. Тем более, что предыдущую проверку мы делали около 3 лет назад, а значит, наверняка найдём в нём новые ошибки.
Очень не хотелось частично повторять введение из прошлой статьи "Выявляем опечатки в проекте GTK 4 с помощью PVS-Studio", но подозреваю, что далеко не все читатели знакомы с GTK. Поэтому вкратце: библиотека позволяет кроссплатформенно реализовывать графический пользовательский интерфейс. Полностью бесплатна и имеет открытый исходный код, лицензированный под GNU GPL, что позволяет использовать её в любых проектах (даже коммерческих).
FreeCAD и C++ код с неопределённым поведением для медитации
Изучая код проекта с помощью статического анализатора, иногда задаёшься вопросом: "Как возникла ошибка и почему её до сих пор не заметили?" Хотите посмотреть пример? Тогда приглашаем познакомиться с этой статьёй.
Поиск ошибок в проектах на основе Unreal Engine
В статическом анализаторе PVS-Studio начали появляться диагностические правила для выявления багов, специфичных для Unreal Engine проектов. Однако без сообщества разработчиков игр здесь не обойтись. Напишите нам про типовые паттерны ошибок, поиск которых хотелось бы автоматизировать.
Анализатор PVS-Studio хорошо выявляет распространённые паттерны опечаток, логические ошибки, потенциальные уязвимости и многое другое. Теперь взор команд, разрабатывающих PVS-Studio, обратился в сторону Unreal Engine.
Ошибка настолько проста, что программисты её не замечают
Нам в поддержку написал пользователь о странном ложном срабатывании анализатора PVS-Studio. Сейчас станет понятно, почему этот случай заслуживает отдельной маленькой статьи и насколько у программистов может быть замылен взгляд.
Распространённые паттерны опечаток при программировании
Есть бесконечное количество способов ошибиться при написании кода. Однако иногда можно заметить явные интересные закономерности, как и где ошибаются программисты. Поговорим о коде, который "притягивает" опечатки.
На чём основаны наблюдения
С целью тестирования и продвижения статического анализатора кода PVS-Studio мы проверяем различные открытые проекты. Найдя ошибки, мы сообщаем о них авторам проектов, коллекционируем их и пишем статьи про наиболее интересные случаи.
Рассматривая все эти ошибки, я постепенно замечаю различные повторяющиеся паттерны опечаток. За редким исключением они не зависят от языка программирования. По крайней мере, они одновременно свойственны коду, написанному на C, C++, C#, Java. В этой статье я опишу 7 паттернов, которые заметил к настоящему моменту:
- Эффект последней строки.
- Злополучная функция memset.
- Неверные функции сравнения.
- Неверные функции копирования.
- Ошибки работы с датами и временем.
- Несчастливые числа: 0, 1, 2.
- Ошибка на единицу (off-by-one error).
Заметность закономерностей в ошибках свидетельствует о том, что они крайне распространены. Полезно знать о них, чтобы избегать написания потенциально опасного кода или более эффективно находить их в процессе обзоров кода. Другим словами, вы узнаете, какой код притягивает ошибки, и будете более внимательно его проверять. Конечно, PVS-Studio способен выявить многие подобные ошибки, но не все. Поэтому дополнительное внимание не повредит.
Review of mini-book «60 terrible tips for a C++ developer»
I wrote a small e-book about terrible tips for C++ developers. Actually, it describes bad programming practices and explains why it's better to avoid them. However, every chapter of this mini-book starts with a terrible tip — just for fun.
By the way, these tips may seem artificial but believe me, they are based on the real experience. In other words, the described terrible tips occur in developers' lives — that's why it's worth discussing them. First of all, this book will be useful for junior developers. But more skilled C++ developers can also find interesting and useful tips.
Even though it's a mini-book, it clearly does not fit into the Habr format. Too many words. So, I decided to write here the review. Here is the link to find the full version of the mini-book: 60 terrible tips for a C++ developer.
If you still hesitate whether to read it or not, below you will find a list of terrible tips that will be discussed in the mini-book.
View the terrible tips:
60 антипаттернов для С++ программиста, часть 12 (совет 56 — 60)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
60 антипаттернов для С++ программиста, часть 11 (совет 51 — 55)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
60 антипаттернов для С++ программиста, часть 10 (совет 46 — 50)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.