Короткий разбор (по пунктам), начиная с вашего примера: в функции записи вы проверяете границы: if (idx>=0 && idx<256) — в KaTeX: (idx \ge 0) и (idx < 256). А в чтении проверка отсутствует, поэтому возможен выход за границы буфера.

Сильные стороны процедурного стиля

Простота и предсказуемость: прямая последовательность вызовов и явное состояние. Хорошо для низкоуровневого кода и отладки.Низкие накладные расходы: минимум runtime/метаданных — важно в встраиваемых системах.Совместимость и портируемость: C-стиль API легко вызывать из других языков и toolchain.Контроль над памятью и временем выполнения — можно добиться максимальной детерминированности.

Слабые стороны процедурного стиля (в больших проектах)

Распространённое глобальное состояние и слабая инкапсуляция → трудно локализовать ошибки.Рост связности: функции зависят от тех же глобальных данных, усложняется рефакторинг.Тестируемость осложняется, если состояние скрыто в модуле/глобалях.Меньше выразительных средств для моделирования доменных сущностей (полиморфизм, наследование, композиция).Проблемы безопасности и конкурентности при нестрогих интерфейсах (отсутствие контрактов, проверки входных данных).

Плюсы и минусы модульной архитектуры

Плюсы: явные интерфейсы, разделение ответственности, легче тестировать/сменять реализацию, локализация ошибок, упрощённый CI/параллельная сборка.Минусы: неверно спроектированные границы модулей «текут» (leaky abstractions), избыточная абстракция замедляет разработку, возможные накладки по памяти/времени в constrained-системах.

Как обеспечить инкапсуляцию, тестируемость и безопасность в чисто процедурном коде

Абстрактные типы данных (ADT)
В заголовке объявляйте неполный тип: typedef struct buffer_t buffer_t; — определение в .c. Это даёт инкапсуляцию состояния при процедурном API.Сквозные интерфейсы и явные контракт‑проверки
Все API-функции проверяют входные параметры и возвращают код ошибки (например, int с константами или enum).В примере: сделать int write_value(buffer_t *b, int idx, int v) и int read_value(buffer_t *b, int idx, int *out); проверять (idx) и возвращать ошибку вместо UB.Ограничение видимости
Используйте static для внутренних функций/переменных в C, атрибуты видимости компоновщика, отдельные object-файлы.Dependency injection и моки
Передавайте указатель на контекст/структуру состояния в функции, чтобы в тестах подставлять фейковые реализации.API минимизации состояния
По возможности избегайте глобальных переменных; если нужны — сделать их приватными внутри модуля и управлять через интерфейс.Контракты и assert
Документируйте предусловия/постусловия; используйте runtime-asserts в debug-сборках.Инструменты безопасности
Статический анализ (clang-tidy, cppcheck), Sanitizers (ASan, UBSan), fuzzing, code review.Конкурентность
Явно документировать, потокобезопасен ли API; в модуле — использовать mutex/atomic, минимизировать разделяемое состояние.Размеры буферов и ограничения
Использовать ширину типов и явные размеры (size_t, uint8_t), чётко проверять границы: (idx \ge 0) и (idx < 256).Тестовая стратегия
Малые единицы (unit tests) для каждого модуля, интеграционные тесты для API, hardware-in-the-loop для встраиваемых.

Когда стоит переходить к объектно‑ориентированному или компонентному подходу

Переход имеет смысл, если проявляются: повторяющийся код связанный с данными, необходимость полиморфизма/расширяемости, сложные жизненные циклы объектов, рост числа взаимодействующих сущностей, командная разработка с разделением ответственности.Практические сигналы:
Один модуль становится большим и изменяется часто.Нужно множество реализаций одного интерфейса (плагинов, драйверов).Требуется инкапсуляция состояния и поведения в единый "объект" для удобства тестирования и поддержки.В встраиваемых системах дополнительно учитывать ресурсы: если память/время критичны — предпочитать ADT/компонентный C-подход или легковесный OOP (структуры + таблицы функций), а не тяжёлые runtime-фичи.Компонентная архитектура (ECS, сервисы) хороша при необходимости гибкой композиции и слабой связности; OOP хороша при естественной «моделируемости» сущностей с поведением.

Краткие рекомендации

Для простых/встраиваемых проектов: процедурный стиль + строгие ADT, видимость и проверки — зачастую достаточно.Если нужна расширяемость, полиморфизм и удобство моделирования — переходите на OOP/компонентный дизайн; используйте его там, где выигрыш в поддерживаемости/скорости разработки превышает накладные расходы.Всегда: чёткие интерфейсы, явная обработка ошибок, автоматические тесты и статический анализ.

Если хотите, могу показать пример безопасного процедурного API (рефакторинг ваших функций) с проверкой и возвращаемыми кодами.