Отдельный “включают” и “src” папки для кода прикладного уровня? [закрытый]

Имеет смысл разделить их для разделяемых библиотек, потому что они могут распространяться в скомпилированной форме без исходного кода. Я видел проекты, которые отделяют «общедоступные» заголовки (заголовки, к которым можно получить доступ из кода вне вашего проекта или библиотеки), оставляя «частные» заголовки и исходные файлы в одном каталоге. Я думаю, что хорошо использовать последовательный подход, пишете ли вы общую библиотеку или код уровня приложения, потому что вы никогда не знаете, когда вы можете захотеть превратить то, что вы написали на уровне приложения, в библиотеку более низкого уровня, которая используется несколькими проекты.

Многое зависит от размера проекта. До нескольких десятков файлов или около того, хранить их в одном каталоге, как правило, удобнее. Для более крупного приложения, которое включает в себя сотни или тысячи файлов, вы начинаете искать способы их разделения (хотя в проектах, над которыми я работал, это было сделано больше в функциональных направлениях, чем в src / include). Между ними это, вероятно, под вопросом.

Я почти всегда создаю папки include и src, чтобы разделить исходный код. Я думаю, что это делает папку менее загроможденной, а файлы в моей IDE легче находить. Но я думаю, это дело вкуса.

Допустим любой метод. Это зависит от стиля кодирования, которому вы хотите следовать.

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

ИМХО, я считаю, что лучше организовывать по темам. Каждая папка темы должна быть встроена как минимум в одну библиотеку. Различные проекты могут легко включать темы путем поиска или включения папок. В проекты нужно включать только библиотеки. Интеллектуальные механизмы сборки могут отображать папки тем как зависимости. Это ускоряет процесс сборки.

Тематическая организация также добавляет проекту немного безопасности. Случайное повреждение файлов (например, удаление неправильных или замена на другие версии) уменьшается, поскольку файлы находятся в разных каталогах. Удаление файлов в папке «Человек» не повлияет на файлы в папке «Форма».

Это всего лишь мое мнение, ваш пробег может отличаться.

Я этого не делаю; в этом, кажется, мало пользы. Поскольку заголовки обычно имеют расширение, отличное от расширения исходных файлов, вы можете настроить отображение их отдельно в редакторе, если вы действительно чувствуете в этом необходимость - Visual Studio делает это по умолчанию, но я отключил его, так как предпочитаю видеть их вместе

На мой взгляд, нет явных преимуществ ни у того, ни у другого. Я окончательно решил держать файлы программы и заголовков вместе, потому что мой редактор (Visual SlickEdit) предоставляет дополнительные ссылочные возможности, когда они не разделены.

У нас есть система сборки, которая использует это правило. Эта система сборки sconspiracy представляет собой набор сценариев для настройки SCons, предназначенных для мира C ++. Вы можете увидеть пример, в котором используются эти инструменты: fw4spl

У нас есть система сборки, которая автоматически генерирует наши make-файлы. Она рекурсивно спускается по всем подкаталогам и собирает их как библиотеки, связывая их вместе с объектами главного каталога для создания приложения. (На практике эти "подкаталоги" обычно являются символическими ссылками.) Библиотеки статичны, если имя каталога не заканчивается на ".so". Приятным моментом является то, что при полной сборке нашей системы, которая содержит много исполняемых файлов, не нужно многократно компилировать общие библиотеки.

Однако в результате этого не происходит разделения заголовков и исходных текстов. И это никогда не было проблемой. Честно говоря, я думаю, что так лучше, потому что заголовки и исходные файлы имеют общее расположение, и вы можете взять каталог и знать, что у вас есть все необходимое для его использования. Это также отлично работает с функцией "externals" в Subversion и аналогичными функциями в других VCS.

Последнее место, где разделение include/src не работает - это использование генераторов кода, таких как flex, bison или gengetopts. Выяснить, куда эти инструменты должны поместить свои результаты, чтобы они были собраны, довольно сложно, если вы все разделили.