Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?
Неважно, новичок ли вы, отлаживающий вашу первую программу «Hello World», или опытный инженер, — у каждого из нас всегда есть возможность улучшить свои навыки. Александр Шелютин, Data Architect в KarmaHQ, расскажет о разнице между тем, как просто заставить что-то работать, и написанием действительно хорошего кода.
Как-то раз Бобу поручили построчно обработать текстовый файл. Боб решил решить эту задачу на C++, так как известно, что мало найдётся языков, которые могли бы потягаться с C++ в скорости. Поскольку C++ для Боба — дело новое, неосвоенное, он решил погуглить спросить ChatGPT, какой способ построчного считывания файла на C++. Для этого потребовалось немного затравочного кода, зато не пришлось пролистывать бесконечные страницы документации по стандартной библиотеке C++.
Боб — джун с большими амбициями. Он всерьёз относится к своему ремеслу и репутации, поэтому ему важно убедиться, что код у него получается аппетитным — быстрым, элегантным и лучшим в своём роде.
💡
После этого Боб выложил окончательную версию кода на GitHub в файле TextFileReader.h, и вы смело можете использовать его в ваших проектах.
Привет, Хабр! Меня зовут Максим Приходский, я архитектор R-Style Softlab и сегодня хочу рассказать вам о проекте создания архитектурного репозитория в git на базе PlantUML.
В этой статье мы рассмотрим, как правильно разрушать объекты в ООП программе на языке C++, не выполняя избыточных операций. Этим мы завершим цикл публикаций, посвящённый обзору ошибок в игровом движке qdEngine.
Привет любителям микро-кодирования. Вот вам кое-что невероятное: крошечный движок raycasting (метод “бросания лучей”) и генератор городов, который помещается в отдельный 256-байтовый HTML-файл.
Я работаю в аутсорсе и недавно вернулась на один из проектов, с которого ушла год назад. К своему глубокому удивлению, ознакомившись с кодом, я поняла, что его никто не рефакторил весь этот год. При разговоре с коллегой, который работал над этим проектом, я выяснила, что время на рефакторинг отдельно не выделялось, и он его не успел провести.
Итак, что я имею сейчас? Что стало с кодом, который не рефакторили год? Вопрос риторический, и так понятно, что он превратился в легаси.
Например, эти замечательные константы под гнетом измененных требований превратились в функции.
В блоге beeline cloud я рассказывал о Spring Data JPA, Hibernate, делился личными наблюдениями, как облегчить себе жизнь при написании тестов. Сегодня речь о другом: расскажу, как инжектить в статические поля. Как всегда — на примерах. Поехали.
На практике десериализаторов, представленных в ядре Spring, хватает в 99% случаев. Но бывают ситуации, когда всё же требуется описать свою логику предобработки входящего сообщения.
Для наглядности предлагаю рассмотреть гипотетический случай, когда на вход Kafka подается строка лога с задаваемым разделителем. В этой строке нас интересует лишь часть сообщения: мы будем делить строку по определенному символу и собирать из получившегося массива новую строку.
Как описать хороший код в трех словах? Исходя из опыта — это код, который [приятно поддерживать и эксплуатировать]. СОЛИД, SOLID, СОЛИД... Редко код ревью обходится без упоминания этих принципов, но для разработчика это не означает ничего хорошего. А что, если я скажу вам, что есть альтернатива? Недавно я наткнулся на одну англоязычную статью в блоге автора по имени Dan North. Он поднимает крайне интересные темы: написание хорошего кода, поддержка кодовой базы, порочные практики следования устаревшим трафаретам.
Думаю, для каждого программиста не секрет, что не всегда есть время и возможность подгонять свое решение под SOLID. Иногда проще оценивать свой код по шкале «хорошего кода» без трафаретов. Тут, конечно, прибегут некоторые люди, которые будут утверждать, что их проекты не содержат говнокода и легаси... Это все просто побег от реальности, нежелание принимать то, что любые проекты и их кодовые базы — это вечные «макароны». В общем, идеализация разработки, которая ни к чему, кроме душевных страданий, не ведет.
В этой статье мы затронем один из самых простых, но в то же время наиболее важных навыков в программировании. Ведь именно грамотное именование кода позволяет говорить о его качестве.
Существует четыре главных фактора, которые отличают хороший код от плохого: читаемость, изменяемость, безопасность и производительность. Первые три — тесно связаны, и главным среди них является именно читаемость.
Ведь читаемость это фундамент, без которого ничего не получится.
В этой статье мы рассмотрим, как статический анализатор PVS-Studio воодушевляет заняться рефакторингом кода. Ведь чем короче, проще и понятнее код, тем меньше в нём ошибок.
Здравствуйте, уважаемые читатели!
В этой статье я хотел бы продолжить тему появления субъязыка текстовых запросов к нейросетям (которая может быть полезна не только для инженеров, но и всех энтузиастов, которые, как, к примеру, и я проводят значительное время за работой с ИИ-генераторами).
Компания Anthropic, которая разработала семейство больших языковых моделей (LLM) Claude представила новый ИИ-инструмент, суть которого заключается в использовании уже готовых, универсальных, оптимизированных текстовых запросов по соответствующим темам, что позволяет повысить скорость и эффективность работы с нейросетевыми ресурсами.
Инструмент и соответствующий раздел веб-сайта Anthropic, на котором он размещен, получили название Prompt Library – Библиотека Запросов – а в качестве подзаголовка представлена фраза Explore optimized prompts for a breadth of business and personal tasks (Осваивайте оптимизированные запросы для решения широкого спектра деловых и личных задач).
Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.
Баги, которые удалось найти в движке qdEngine, оказались весьма разнообразны, поэтому не хочется мешать всё в кучу в одной публикации. Читатели могут упустить интересные темы, связанные с написанием качественного кода. Поэтому разбор проекта выйдет в виде серии публикаций, первая из которых посвящается наиболее интересным срабатываниям с точки зрения плагина PVS-Studio.
Любому программисту знакомо понятие "ссылка". Под этим термином обычно понимают небольшой объект, главная задача которого обеспечить доступ к другому объекту, физически расположенному в другом месте. Из-за этого ссылки удобно использовать, они легко копируются, и с их помощью очень просто получить доступ к объекту, на который эта ссылка ссылается и можно получить доступ к одним и тем же данным из разных мест программы.
К сожалению ссылки, точнее ручное управление памятью, является наиболее частой причиной возникновения различных ошибок и уязвимостей в программном обеспечении. А все попытки автоматического управления памятью с помощью различных менеджеров упираются в необходимость контролировать создание и удаление объектов, а также периодически запускать сборщик мусора, что отнюдь не положительно сказывается на производительности приложений.
Тем не менее, ссылки в той или иной форме поддерживаются во всех языках программирования, хотя под этим термином часто подразумеваются не полностью эквивалентные термины. Например, под словом "ссылка" можно понимать ссылку как адрес в памяти (как в С++) и ссылку, как указатель на объект (как в Python или Java).
Хотя встречаются языки программирования, которые пытаются решать данные проблемы за счет концепции "владения" (Rust, Аргентум или NewLang). О возможном решении этих и других имеющихся проблем со ссылками далее и пойдет речь.
Привет, Хабр! Меня зовут Грант, я уже 5 лет занимаюсь backend-разработкой в SimbirSoft, а с 2021 года возглавляю Backend-отдел компании в Краснодаре. В последние несколько лет неоднократно замечаю, что на входном интервью соискатели часто путают принципы разработки. Поэтому в этой статье решил разобрать, как проще их понимать, какие связи между ними прослеживаются, стоит ли учить все или что-то можно пропустить. А еще попробую раскрыть некоторые особенности, какие секреты скрывают популярные принципы разработки.
Всем привет! Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture и у вас могли остаться спорные вопросы как в сложности понимания материала, так и в реализации данных подходов в ваших проектах. Сегодня я хочу затронуть тему “Организации кода” и показать насколько это важно и легко одновременно на примере Layer Architecture (Слоистая архитектура).
Статические анализаторы помогают не только обнаруживать ошибки и дефекты безопасности, но и делать код чище. Выявляя лишние проверки, дублирующие действия и другие аномалии, можно сделать код проще, красивее и легче для чтения. Разберём это на практическом примере рефакторинга функции.
