Макет исходного кода проекта C ++

Question

Один из популярных способов организации каталогов проектов более или менее похож на этот:

MyLib
     +--mylib_class_a.h
        mylib_class_a.cpp
        mylib_library_private_helpers.h
        mylib_library_private_helpers.cpp

MyApp
     +--other_class.h
        other_class.cpp
        app.cpp

app.cpp:

#include "other_class.h"
#include <mylib_class_a.h> // using library MyLib

Все файлы .h и .cpp для одной библиотеки находятся в одном каталоге. Чтобы избежать конфликта имен, имена файлов часто имеют префикс с названием компании и / или именем библиотеки. MyLib будет в пути поиска заголовка MyApp и т. Д. Я не фанат префиксов имен файлов, но мне нравится идея взглянуть на #include и точно знать, где находится этот заголовочный файл. Я не ненавижу такой подход к организации файлов, но я думаю, что должен быть лучший способ.

Поскольку я начинаю новый проект, я хочу запросить некоторые идеи организации каталогов. В настоящее время мне нравится эта структура каталогов:

ProjA
    +--include
             +--ProjA
                    +--mylib
                           +--class_a.h
                    +--app
                           +--other_class.h
    +--src
         +--mylib
                +--class_a.cpp
                   library_private_helpers.h
                   library_private_helpers.cpp
         +--app
              +--other_class.cpp
                 app.cpp
                 util.h

app.cpp

#include "util.h" // private util.h file
#include <ProjA/app/other_class.h> // public header file
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision
#include <class_a.h> // not ProjA/mylib/class_a.h
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h 

.cpp файлы и личные (видимые только для непосредственной библиотеки) .h файлы хранятся в каталоге src (src иногда называют lib). Открытые заголовочные файлы организованы в структуру каталогов project / lib и включены через <ProjectName/LibraryName/headerName.h>. Имена файлов не имеют префикса с чем-либо. Если мне когда-нибудь понадобилось упаковать MyLib для использования другими командами, я мог бы просто изменить свой make-файл, чтобы скопировать соответствующие двоичные файлы и весь каталог include / ProjA.

Как только файлы будут проверены в системе контроля версий и люди начнут работать с ними, будет сложно изменить структуру каталогов. Лучше получить это прямо на старте.

Кто-нибудь с опытом организации подобного исходного кода? Что-нибудь тебе не нравится в этом? Если у вас есть лучший способ сделать это, я бы очень хотел услышать об этом.

Answer 1

Ну, все зависит от того, насколько велики эти проекты. Если у вас есть только несколько файлов, поместите их в одну папку.

Слишком много папок, когда у вас мало файлов для управления, на мой взгляд, излишне. Это раздражает копаться в папках и папках, когда в них всего несколько файлов.

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

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

KISS обычно всегда является решением в программировании -> сделайте все максимально простым.

Answer 2

Почему бы не сделать что-то подобное первому, используйте только каталог, в котором находится MyLib, как часть директивы include, которая уменьшает глупый префикс:

#include <MyLib/ClassA.h>

Это говорит вам, откуда они. Что касается второго варианта, меня лично очень раздражает, когда у меня открыт заголовок или исходный файл, и мне приходится перемещаться по структуре каталогов, чтобы найти другой и открыть его. Во втором примере, если у вас открыто src/mylib/class_a.cpp и вы хотите отредактировать заголовок, во многих редакторах вам придется вернуться на два уровня назад, затем в include/ProjA, прежде чем найти заголовок. И как нам узнать, что заголовок находится в подкаталоге ProjA без какой-либо другой внешней подсказки? Кроме того, один или другой файл слишком легко перенести в другое место, что «лучше» представляет его использование без перемещения альтернативного файла. Это просто вызывает у меня головную боль, когда я сталкиваюсь с этим на работе (и у нас есть некоторые части нашей базы кода, где люди решали все потенциальные проблемы, которые я только что упомянул).

Answer 3

Я пробовал оба метода. Лично мне больше нравится первый. Я понимаю необходимость помещать все в более конкретные каталоги, но это вызывает много чрезмерных осложнений.

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