Хочется писать красивый и правильный код.

Сейчас активно использую глобальные переменные и типа, если надо чтобы один модуль записывал данные, а другой их читал, то объявляю буфер как
extern buf[256];

Вобщем понимаю что не комильфо всё это. Но иные варианты сами в голову не приходят, прошу помочь.

Сначала надо определиться, что именно здесь некрасиво и неправильно. Я, например, не вижу проблем.

проблема в том, что буфер объявлен как глобальный в одном модуле proc.c, а в другом модуле main.c происходит его чтение, и там он объявлен как extern buf

ну и собственно глобальные переменные - это не правильно.

Разве нет?

Нет.

Вы ведь еще можете его передавать свой массив, как аргумент в функцию. Точнее не сам массив, а указатель на него. (Хотя инкапсуляцией тут и не пахнет)

И я тоже не вижу ничего плохого в глобальных переменных, если они подходят к контексту.

Это увеличивает связность кода и соответственно усложняет его понимание.
Как по мне так лучше в одном файле обьявить static array.
И написать функции работы с ним (чтение и запись), которые будут видны в других файлах.
Так гораздо удобнее отлавливать баги связанные с массивом, и проще понять где было произведено чтение или модификация массива.

Если надо красиво и правильно, но все объявления extern-объектов следует делать в отдельном хидере.
Например, в
global.h
куда вписать все extern-определения.

А чтобы и сами глобальные объекты не расползлись по разным модулям, то их желательно тоже поместить в отдельную корзину.
Например, собрать их всех в модуле
global.c
или завести себе правило объявлять глобальные переменные только в модуле main.c
(тогда и global.h можно обозвать main.h).

А в самих сишных модулях слово extern никогда (!) не должно встречаться, а допустимо лишь включать
#include "global.h"
или
#include "main.h"

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

Ага. Свалим все в одну кучу, сделаем одну большую тарелку с макаронами, в которой станет почти невозможно отделить мух от котлет. Афигенно красиво. И настолько же правильно.

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

Упаси Боже так делать )

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

Ну, путь объявления.


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

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

Я тоже без особой нужды ничего не открываю. Доступ извне к массиву, объявленному в модуле - через функцию. Это не засоряет пространство имен внутри модуля.
Хоть 100500 одинаково названных queue, но определенных в разных модулях.

Такой подход имеет право на существование, однако у него все же есть два недостатка:
- Пространство имен функций все-таки засоряется. Не получится иметь 100500 функций init();
- На вызов функции и возврат из нее тратится время и память кода. Напрямую с переменной работать эффективнее.

Зачем, ну объясните мне, зачем делать эту общую свалку global.h? Только ради того, чтобы в каждом исходнике писать одну строчку #include "global.h" вместо нескольких, по которым будет совершенно однозначно видно, какие именно другие модули использует этот? И какие файлы надо захватить вместе с этим при копировании этого модуля в другой проект?

И что-то я не понял насчет "подключается дополнительно". Если уже подключен заголовочный файл модуля А.h, то включены все необходимые объявления модуля A. Что тогда будет в global.h?

Со временем устаканилось две вещи (как ответ на "два недостатка"):
1. Там, где надо 100500 ИНИТов делать - это решается через хэндлы. Как говорят военные, безобразно, зато единообразно.

2. Там, где требуется оченно зашкаливающая эффективность, - там нет таких объемов данных и все сосредоточено в пределах одного модуля.
Это все фигня, потому что С++ все-таки дает неквадратные колеса. Если человеку аж чешется ООП, то для чего этим страдать на Си? На Си даже try - catch можно делать, ну и?
На GCC можно даже частично RTTI на макросах делать. Но к чему?

Чтобы пихать туда вещи, которые не принадлежат ни к одному модулю. Глобальные переменные например.
В глобально доступных переменных нет сильно большого криминала до тех пор, пока к ним доступ осуществляется атомарно в многопоточных программах. И пока не страдает логика приложения, например всё приложение начинает управляться глобальными флагами.

Вот и я о том. когда всё приложение сводится к
while(1)
и опросу глобальных флагов
if (x == 1)

то это не хорошо

как избежать?

Приложение может строиться разными способами. Ваша задача подобрать такой способ, который будет удобен для вас и расширяем для потенциального роста приложения.
1. Либо это суперлуп (главный цикл) с флагами. Для небольших приложений.
2. Либо это взаимодействие конечных автоматов. Для приложений чуть побольше.
3. Традиционный многопоточный подход с обменом сообщениями между потоками. Почти любого масштаба приложений, но требует высокой квалификации программиста.
4. Всякие вариации в сторону декларативного и функционального программирования. Требует поддержки от компилятора.

Это я навскидку составил список. Если упростить, то нужно делать по максимуму модульную программу. Там где это возможно, глобальные флаги заменять на вызов функции соответствующего модуля (например uart_is_data_ready()). Для передачи массива данных делать копию для обработки в подходящем модуле. Граф зависимостей модулей не должен (не желательно) иметь циклы. Если модуль A зависит от модуля Б, а модуль Б от модуля А, то цикл нужно разорвать.

Инкапсуляция является одним из подходов к ООП, а С как известно к таким языкам не относится.
Тем не менее, пару раз попадался красивый код на чистом С, реализующий инкапсуляцию(поразила красивая работа со структурами).

В Вашем конкретном случае с буффером, можно например передавать в функцию указатель на другую функцию, которая и будет вызываться. А вообще, лучше использовать С++