Как грамотно разбить программу на несколько файлов?

[Gene1982]

Я пишу программу, которая находится в одном C файле, содержит около 1000 строк и 16 функций.
Я добавляю новые функции и программа постепенно увеличивается. Не могу сказать, какой объем будет у программы в итоге.
Я не профессионал в программировании, поэтому хочется узнать, как грамотно и профессионально разбить эту программу. Надо ли делать отдельные C файлы для каждой функции или делать отдельные C файлы для нескольких функций, или вообще не стоит разбивать на несколько файлов программу такого объема?

[Majestio]

Для такого объема особого смысла в разбиении нет - слишком мало кода. Но по фэн-шую надо бы завести себе определенные правила, которые в будущем помогут не путаться в коде. Приведу некоторые, но это не стандарт и не абсолют конечно!

1. При создании проекта сразу строить грамотную файловую иерархию проекта. Среди моих обязательных подкаталогов - docs, src, tests. Названия говорят сами за себя;
2. В подкаталоге src содержится весь исходный код проекта. Ему также нужна иерархия - в корне этого подкаталога, скажем так, "общие файлы проекта", в подкаталогах типа net, db, math - файлы проекта, сгруппированные по назначению;
3. В тематических подкаталогах исходного кода давать файлам уникальные имена, используя префикс, типа db-common.c, net-common.c & etc. Но не common.c - потом при поиске будет неудобно.

Отдельно про дробление кода по файлам

В идеале - нужна одна функция на одну единицу трансляции (на файл), особенно если потом все это собираешь в собственные библиотеки. Этим самым облегчается задача линкеру - брать в исполняемый файл только тот код, который задействован в программе, неиспользуемые функции не включать. "Мертвого кода" не будет изначально, даже не используя специальные ключи сборки. Но, как я написал сразу - это в идеале. Потому как количество файлов уже в среднем проекте будет достаточно большим. Поэтому нужен компромисс - объединять в файлах функции, которые всегда работают вместе, и разделять их по файлам смысла нет. Например, open_db и close_db. По отдельности их обычно не используют - поэтому их в один файл. Четких определений разделения нет, но вот такая концепция имеет место. Но это мой личный подход, народ имеет свои взгляды и вариации

[ЫукпШ]

Цитата Gene1982 @ 09.03.23, 08:10

.. хочется узнать, как грамотно и профессионально разбить эту программу.

Главное, чтобы тебе было удобно.
---
Объединять функции в модули можно по функциональному назначению.
Например, обслуживание настроек - свой модуль, COM-порт - свой модуль,
мат-вычисления... итд.
---
Если будем делить проект на модули, тогда создадим хеадер с прототипами,
которые представлены группами. С указанием модуля, к которому они принадлежат.
В идеале, прототипы даже перечислены должны быть в том же порядке, как функции размещены в модуле.
Так легче отыскивать функции при сопровождении большого проекта.
---
Все определения сделаем в хеадерах, все хеадеры разместим в одном файле.
Например, "project.h"
---
В модуль с функцией "main" больше ничего не будем добавлять.
Этот модуль так и назовём "main.c"
---
И ещё мне понравилось - прочитал в Сети:
"Плохо, когда функция main не влезает в экран"
На мой взгляд, это касается любой функции.
Но без экстремизма, по возможности.
Возможности бывают разные.
---
Однажды я видел, как мужик подключил к Виндусу 2-й монитор
16x9 и поставил его набок. Если мелким фонтом, тогда можно
делать функции очень длинными.

Сообщение отредактировано: ЫукпШ - 09.03.23, 15:00

[Feldsher]

Все соберется в 1 EXE после компиляции и компоновки, разбивать как удобнее