Organizacja plików w projektach C++ - pytanie o dobre praktyki

Hej,
Programując w Unity, zawsze tworzyłem sobie hierarchię folderów na skrypty, dzięki czemu wszystko było uporządkowane. Ostatnio wróciłem do C++ i sprawdziłem kilka większych programów programów open-source. Zauważyłem, że wszystkie skrypty są w jednym folderze, a ewentualnie headery w innym. Czy w C++ zazwyczaj wszystko daje się właśnie do jednego folderu, czy istnieją jakieś dobre zasady tworzenia i porządkowania tych plików?

To jaka struktura katalogów będzie zależy od programisty, jak stosuje jakieś DDD domain driven development, to będzie miał katalogi podzielone na domeny.
Np. jakiś hotel, to np. rezerwacje, zakupy, powiadomienia, czy coś innego, zaleźnie od domeny.

W każdym takim katalogu będzie miał useCasey jak ludzie mogli by korzystać i implementacje.

Może być teź jak w web developmencie, jakieś router, czyli folder gdzie wszystkie wejścia post/get/update/delete są rozwiązywane, czy innne jak app, database, model, zależy od człowieka jak zaprojektuje.

To zależy kto jaką ma wizję i jakie doświadczenie, im lepiej zrobisz strukturę katalogów tym potem łatwiej się odnaleźć gdzie co powinno być.
Jak ktoś wszystko do jednego daje, to albo to bardzo mały projekt nawet nie ma co rozdzielać, a jak duży i wszystko wymiesza to trudno się odnaleźć.

To jest też trudne dobrze zaprojektować dla danego problemu odpowiednią strukturę, trochę danej domeny trzeba znać.

Zalezy od wielu rzeczy. Osobiscie preferuje takie podejscie, ze jesli pisze jedna prosta aplikacje, to mam po prostu folder src z plikami hpp i cpp, a w systemie budowania dodaje ten folder do sciezek include, dodatkowo zawsze sobie namespacuje, tzn jesli moj projekt nazywa sie foo, to bede mial <root>/src/foo, co mi daje potem ladne includy w postaci #include <foo/a/b/c.hpp>

jesli pisze libke, to mam osobny folder na include i na src, ale rowniez znamespaceowane, tzn <root>/include/foo oraz <root>/src/foo/*.cpp

generalnie jednak rzeadko bardzo zdarza mi sie miec tylko jedna apke czy jedna libke, zazwyczaj projekt sklada sie z X libek i jednej lub wiecej apek, wtedy w folderze src albo projects mam je wszystkie i wyglada to np .tak:

├── src
│   ├── meson.build -- jakis plik do budowania do spiecia wszystkiego
│   ├── app-name
│   │   ├── meson.build -- plik budowania konkretnie tej apki
│   │   └── src
│   │       └── app-name
│   │           └── main.cpp -- pliki cpp
│   └── app-name-core -- w tym przypadku glowna libka apki
│       ├── include
│       │   └── app-name-core
│       │       └── foo.hpp -- publiczne headery
│       ├── meson.build
│       └── src
│           └── app-name-core
│               ├── foo.hpp -- prywatne headery
│               └── foo.cpp -- i pliki zrodlowe

@MaszynaDoSzycia: Rób jak chcesz. Nie ma raczej żadnych odgórnych dobrych praktyk. Dużo zależy od projektu. Jak projekt jest duży to warto sobie posegregować, ale jak będziesz trzymać wszystko w jednym folderze to raczej żadna tragedia się nie stanie.
Zdecydowanie ważniejsze jest odpowiednie dobranie hierarchii plików i rozdzielenia elementów tak, by nie było błędów albo zapętlonego dołączania.

Dla cmake tu jest opisany dobry wzorzec jego używania (lubię dobre praktyki od Json Turner-a):

Zalezy co robisz i co ma z tego wyjśc
Jak praca zaliczeniowa i tylko zaliczyczyc to moze byc jakkolwiek
Nie skupiał bym sie na hierarchi katalogow raczej wybrał bym dobre narzedzie do budowania
Ja sobie nie wyobrażam zbudowania hello world bez cmake i tego wszystkiego co oferuje
Wiec ja bym zaczał od nauki cmake , ewentualnie mozesz sie posiłkowac gotowymi szablonami cmake dostepnymi na github

To zła praktyka, bo w modularyzacji generalnie chodzi o to, żeby moduły miały jakieś granice. Wrzucenie wszystkiego do jednego wora utrudnia utrzymanie tych granic. Dobrą metryką modularyzacji jest ile rm/mv trzeba wykonać, żeby usunąć/przenieść dany moduł. W przypadku splitu ta liczba rośnie dwukrotnie.

Z drugiej strony sytuacja w C++ jest kłopotliwa. W przypadku bibliotek pliki .cpp mają sens jedynie w czasie kompilacji biblioteki natomiast część headerów stanowi publiczny interfejs biblioteki. W takiej sytuacji include/ / src/ split wydaje się być sensownym rozwiązaniem. Tutaj czystość kodu przegrywa z tooligniem: w C++ panuje dziki zachód jeśli chodzi o budowanie kodu i podział na oddzielne katalogi ma sens, jeśli chcemy, żeby nasz projekt budował się z każdym systemem do budowania

Jakiś czas temu, kilka miesięcy. Do sieci, wyciekł kod źródłowy pierwszego FarCry. Jeżeli Cię interesuje, jak wygląda struktura w poważnych projektach to myślę że warto żebyś sobie zerknął. Co więcej obecna wersja CryEngine jest do znalezienia na Githubie. Możesz też sprawdzić kod źródłowy Dooma 3 BFG.