Проект из многих файлов на C, Как использовать заголовочные файлы? Опции

[ViKo]

Давно терзаюсь вопросами.
Имею проект из нескольких c-файлов. Один из них - главный, main.c, в остальных - некие функции (как разбить проект на части - тоже вопрос смутный, как и понятия "драйвер", "core").
Чтобы функции могли вызываться из любого файла, нужно описать их прототипы. Я их описываю в заголовочных h-файлах, соответствующих c-файлам (display.c - display.h). А чтобы не включать всю кучу h-файлов во все c-файлы, собрал их в одну кучу в main.h. Вот его и включаю во все c-файлы (и в main.c тоже). Где-то видел, такие h-файлы называются "helper".
Чтобы h-файлы не включались в проект по нескольку раз, заключаю все содержимое в макроопределения:

Код

#ifndef DISPLAY_H
#define DISPLAY_H
...
#endif

Также есть отдельные h-файлы, для частных включений.
С глобальными переменными дело обстоит чуть сложнее. В своем файле они должны быть определены, а в остальных заданы, как extern. Для этого пользуюсь макроопределениями (создал в main.h):

Код

#ifndef VAR_DECLS
#define _DECL extern
#define _INIT(x)
#else
#define _DECL
#define _INIT(x) = x
#endif

Только в одном main.c файле задаю определение #define VAR_DECLS, поэтому все переменные будут определены в main.c, независимо от того, в каком h-файле они описаны.

Не слишком ли я запутываю свои проекты? Например, гложет мысль, как правильнее - использовать display.h в main.h или в display.c?
Поделитесь своими решениями. По каким критериям разбиваете проект на файлы? Где храните переменные?
Как передаете глобальные макроопределения (например, #define BUFF_SIZE 4096)?

[AlexandrY]

Не слишком ли я запутываю свои проекты? Например, гложет мысль, как правильнее - использовать display.h в main.h или в display.c?
Поделитесь своими решениями. По каким критериям разбиваете проект на файлы? Где храните переменные?
Как передаете глобальные макроопределения (например, #define BUFF_SIZE 4096)?

Нет не запутываете, вы просто копируете в принципе неплохие практики продвигаемые Micrium-ом и другими.

Но это еще приемлемо для небольших проектов в пару десятков файлов.
А если в проекте счет файлам идет на сотни (а это средненький дивайс с GUI, FS, TCP, RTOS ), то этот подход не работает.

Представьте себе main.h с этаким списком в несколько сот заголовочных файлов. Только взглянув на такой поплохеет.
Управлять таким и разруливать взаимозависимости просто катастрофа.
Проект обязательно надо преобразовать в иерархическую структуру.

Поэтому если хотите делать серьезные проекты сразу думайте над иерархией.
Иерархия это например: плата (BSP), платформа (PSP), архитектура/драйвера, приложение.
Также стоит сразу думать о реюзинге. Отсюда может следовать, что не стоит располагать все глобальные переменные в одном файле.
Потом стоит подумать о многозадачности, это может потребовать как можно больше глобальных переменных скомпоновать в структуры чтобы превратить их потом в динамически создаваемые.
И т.д.
Что касается разбивки на файлы, то могу назвать пару критериев.
Как только размер файла подошел к 50 Кб, то его надо как-то разбить, а то время скролинга исходников начинает неявно доминировать в процессе разработки.
Если планируется реюзинг каких-то модулей, то эти модули разделяются на файлы зависимые и независимые от платформы.
Опять же реюзинг заставляет изобретать уровни абстракции, это тоже порождает файлы.

[ViKo]

Представьте себе main.h с этаким списком в несколько сот заголовочных файлов. Только взглянув на такой поплохеет.
Управлять таким и разруливать взаимозависимости просто катастрофа.

Смотрю на примеры с USB, и не въезжаю, что какие файлы делают. Вот их там пара десятков и есть, но не запомнить, где что искать. Много мелких файлов запутывают.
С другой стороны, файлы своих исходников есть и больше 150 KB. Да, искать напрягает, Notepad++ пыхтит вместе со мной, зато знаю, что оно где-то там.
Количество файлов как раз под два десятка подбирается. И в них есть и GUI, и RTOS, и DSP. А еще надо и USB, FS...
Пока держу все в одном каталоге. Но Keil уже сам создает несколько папок с исходниками в проекте.
И еще хочется как-то уровнять файлы по размеру, тоже ищу логику, как делить.

[AlexandrY]

Да, искать напрягает, Notepad++ пыхтит вместе со мной, зато знаю, что оно где-то там.

Ну так с этого и надо было начинать. Кто же в Notepad-е делает серьезные проекты.
Брать надо SlickEdit или на худой конец Eclipse со специальными add-on-ами.

А так конечно упретесь. Ни нормального броузинга исходников, ни рефакторинга. Тут хоть где объявляйте хидеры. Легче не станет.
Да еще все в одной директории.
Память не резиновая, не надо ее напрасно тренировать поиском по линейным спискам.
Используйте более гибкие иерархические структуры и деревья. Память их лучше обрабатывает.

[ViKo]

Ну так с этого и надо было начинать. Кто же в Notepad-е делает серьезные проекты.
Брать надо SlickEdit или на худой конец Eclipse со специальными add-on-ами.

SlickEdit не пользовался, в Notepad++ найдется все, что нужно, я думаю. И плагины у него тоже есть.
Вопрос не в редакторе, а в голове.

[_Pasha]

SlickEdit не пользовался, в Notepad++ найдется все, что нужно, я думаю. И плагины у него тоже есть.
Вопрос не в редакторе, а в голове.

Попробуйте Geany. Лучше нотепадов однозначно.
Вкратце.
Проект в geany - это просто набор открытых файлов. Для маленького проекта никаких дополнительных телодвижений не нужно - TAGS и автодополнения работают автоматом.
Если кол-во файлов такое, что заметны тормоза - делается tags-файл на используемые либы и продолжаете в том же духе.
Но эклипс все равно круче.