Рубрика «качество кода»

Призыв писать компактное ПО, версия 2024 года (с примером кода) - 1

Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean SoftwareЧитать полностью »

Становится ли ПО хуже? - 1


Недавно я наткнулся на пост Никиты Прокопова Software disenchantment. Он заставил меня вспомнить пост Мацея Цегловски The Website Obesity Crisis и множество других статей подобного типа. Среди людей, пишущих о разработке ПО, возникает всё более широкий консенсус о том, что приложения становятся больше, медленнее и забагованнее. И это в эпоху, когда оборудование должно позволить нам писать быстрее, меньше и надёжнее. DOOM, вышедший в 1996 году, можно запустить в тесте на беременность и на сотне других неожиданных устройств. Тем временем, современные чат-приложения, работая в фоновом режиме, занимают полгигабайта ОЗУ (или больше), а иногда полностью зависают даже на самом мощном ПО.

Вышеупомянутые посты по этой теме состоят примерно на 80% из справедливой и разумной критики, а на 20% из оторванного от реальности ворчания.

Большинство разработчиков понимает, что глупо спрашивать «это ОС для смартфонов, что в ней может быть сложного?» или «моё приложение для работы с электронными таблицами в 90-х занимало 10 килобайт, тогда почему Factorio весит целый гигабайт?» Если вы не присутствовали при разработке, то не сможете оценить все её проблемы и сложности.

Но это не значит, что для объективной критики нет места. Приложения действительно медленнее, чем были раньше. И экспоненциально больше, хотя степень их полезности не растёт с той же скоростью. По крайней мере, почти в каждом современном приложении есть возможности для оптимизации. Мы можем сделать их быстрее, вероятно, даже на порядки величин. Мы можем удалить код. Мы можем писать крошечные специализированные библиотеки. Мы можем находить новые способы сжимать ресурсы.

Почему же мы этого не делаем?Читать полностью »

1053_60_cpp_antipatterns_ru/image2.png

Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.

Читать полностью »

Новая Си++ диагностика для PVS-Studio

Пользователи иногда спрашивают, как появляются новые диагностики в статическом анализаторе PVS-Studio. Мы отвечаем, что черпаем вдохновение из разнообразнейших источников: книг, стандартов кодирования, собственных ошибок, писем наших пользователей и так далее. Сегодня мы придумали новую интересную диагностику и решили рассказать историю, как это произошло.

Читать полностью »

PVS-Studio охраняет сон программиста

Попробовать статический анализатор кода легко. А вот, чтобы внедрить его, особенно в разработку большого старого проекта, потребуется умение. При неправильном подходе анализатор может добавить работы, замедлить разработку и демотивировать команду. Давайте кратко поговорим, как правильно подойти к интеграции статического анализа в процесс разработки и начать его использовать как часть CI/CD.
Читать полностью »

Как писать меньше кода и получать больше толку - 1

Как справедливо заметил легендарный писатель Жюль Верн: «Хорошо использованный минимум вполне достаточен». В нашу эпоху понятие хорошо использованного минимума применимо и к коду. Печально, но факт: в современном мире кода слишком много. Если быть точнее, то слишком много ненужного кода, среди которого код полезный просто задыхается.

Учитывая вышесказанное, ненужный код – это зло по умолчанию. Он портится со временем. Он требует постоянной поддержки. Он содержит баги, которые нужно выискивать. Когда появляются новые функции, старый код приходится к ним приспосабливать. Чем больше у вас кода, тем больше ошибок может в нем затаиться. Чем больше времени занимают проверки или компиляции, тем дольше новый сотрудник будет разбираться в вашей системе.

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

Держи багОбщаясь с людьми на конференциях и в комментариях к статьям, мы сталкиваемся со следующим возражением: статический анализ сокращает время на нахождение ошибок, но отнимает время у программистов, что нивелирует пользу от его использования и даже наоборот тормозит процесс разработки. Давайте разберём это возражение и покажем, что оно беспочвенно.
Читать полностью »

Из документации Google's Engineering Practices

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

См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.
Читать полностью »

Использование статического анализатора PVS-Studio при разработке для встраиваемых систем на C и C++ - 1Из этой статьи вы узнаете, как запустить проверку embedded-проекта и как работать с отчетом анализатора. Анализатор PVS-Studio поддерживает ряд компиляторов для встраиваемых систем. В текущей версии возможна проверка проектов при сборке одним из следующих компиляторов под Window, Linux и macOS:

Читать полностью »

Picture 1

Это небольшая история о том, как с помощью PVS-Studio удалось найти ошибку в исходном коде библиотеки, используемой в PVS-Studio. Причём не теоретическую, а фактическую — ошибка проявлялась на практике при использовании библиотеки в анализаторе.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js