C++ Projekt Quellcode Layout

Question

Eines der beliebtesten Wege Projektverzeichnis zu organisieren, ist mehr oder weniger wie folgt aus:

 
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 

Alle .h und .cpp Dateien für die gleiche Bibliothek sind im selben Verzeichnis. Um Namenskonflikte zu vermeiden, werden Dateinamen oft mit dem Firmennamen und/oder dem Bibliotheksnamen vorangestellt. MyLib wird in MyApps Header-Suchpfad usw. sein. Ich bin kein Fan von Dateinamen, aber ich mag die Idee, die #include zu betrachten und genau zu wissen, wo diese Header-Datei gehört. Ich hasse diesen Ansatz nicht, Dateien zu organisieren, aber ich denke, es sollte einen besseren Weg geben.

Seit ich ein neues Projekt starte, möchte ich einige Ideen für die Verzeichnisorganisation einholen. Derzeit möchte ich diese Verzeichnisstruktur:

 
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 Dateien und private (nur sichtbar für sofortige Bibliothek) .h Dateien im src-Verzeichnis gespeichert werden (src manchmal lib genannt). Öffentliche Header-Dateien sind in einer Projekt/Lib-Verzeichnisstruktur organisiert und enthalten <ProjectName/LibraryName/headerName.h>. Dateinamen haben keine Präfixe. Wenn ich MyLib jemals für andere Teams verwenden wollte, konnte ich einfach mein Makefile ändern, um die entsprechenden Binärdateien und das gesamte include/ProjA-Verzeichnis zu kopieren.

Sobald Dateien in die Quellcodeverwaltung eingecheckt sind und die Leute anfangen, daran zu arbeiten, wird es schwierig sein, die Verzeichnisstruktur zu ändern. Es ist besser, es sofort richtig zu machen.

Jeder mit Erfahrung mit der Organisation von Quellcode wie folgt? Alles was dir nicht gefällt? Wenn Sie einen besseren Weg haben, würde ich gerne etwas darüber erfahren.

Answer 1

Nun, alles hängt davon ab, wie groß diese Projekte sind. Wenn Sie nur ein paar Dateien haben, dann schlagen Sie alle in einen Ordner.

Zu viele Ordner, wenn Sie nicht viele Dateien verwalten müssen, ist meiner Meinung nach Overkill. Es wird nervig, Ordner ein- und auszugraben, wenn Sie nur ein paar Dateien darin haben.

Auch hängt es davon ab, wer dieses Zeug verwendet. Wenn Sie eine Bibliothek schreiben und diese von anderen Programmierern verwendet wird, sollten Sie die Header, die sie verwenden möchten, in einem Include-Ordner organisieren. Wenn Sie eine Reihe von Bibliotheken erstellen und alle veröffentlichen, funktioniert Ihre Struktur möglicherweise. Wenn es sich jedoch um unabhängige Bibliotheken handelt und die Entwicklung nicht alle zusammen erfolgt und sie zu unterschiedlichen Zeiten versioniert und veröffentlicht werden, sollten Sie besser darauf achten, alle Dateien für ein Projekt in einem Ordner zu speichern.

In der Tat würde ich sagen, alles in einem Ordner zu halten, bis Sie zu einem Punkt kommen, wo Sie seine unmanagable finden, dann zu einem cleveren Schema der Aufteilung der Quelle in Ordner wie Sie getan haben. Sie werden wahrscheinlich wissen, wie es von den Problemen organisiert werden muss, denen Sie begegnen.

KISS ist normalerweise immer die Lösung in der Programmierung -> halte alles so einfach wie möglich.

Answer 2

Ich habe beide Methoden ausprobiert. Persönlich mag ich das erste besser. Ich verstehe den Drang, alles in spezifischere Verzeichnisse zu stecken, aber es verursacht viel Überkomplikation.

Normalerweise verwende ich diese Regel: Anwendungen und interne Bibliotheken verwenden die erste Methode. Öffentliche Open-Source-Bibliotheken verwenden die zweite Methode. Wenn Sie den Code freigeben, hilft es sehr, wenn sich die Include-Dateien in einem separaten Verzeichnis befinden.

Answer 3

Warum so etwas wie die erste nicht tun, nur das Verzeichnis verwenden, die MyLib als Teil der Richtlinie enthalten wohnt, die die dummen Vorfixierung reduziert:

#include <MyLib/ClassA.h> 

, der Ihnen sagt, woher sie kommen. Was die zweite Möglichkeit betrifft, ärgere ich mich persönlich sehr, wenn ich eine Kopf- oder Quelldatei geöffnet habe und durch die Verzeichnisstruktur navigieren muss, um die andere zu finden und sie zu öffnen. Bei Ihrem zweiten Beispiel, wenn Sie src/mylib/class_a.cpp geöffnet hatten und die Kopfzeile bearbeiten wollten, müssten Sie in vielen Editoren zwei Ebenen zurückgehen und dann in include/ProjA, bevor Sie die Kopfzeile finden. Und wie sollen wir wissen, dass der Header im ProjA Unterverzeichnis ohne irgendeinen anderen externen Hinweis liegt? Außerdem ist es zu einfach, dass die eine oder die andere Datei an einen anderen Ort verschoben wird, der "besser" darstellt, wie sie verwendet wird, ohne dass die alternative Datei verschoben wird. Es macht mir nur Kopfschmerzen, wenn ich es bei meiner Arbeit treffe (und wir haben einige Teile unserer Codebasis, wo Leute jedes mögliche Problem, das ich gerade erwähnt habe, getan haben).