3. Wie strukturiert ihr Zuhause eure Projektordner?

Wie strukturiert ihr Zuhause eure Projektordner?

  • ?

    Als Progger kommt es ja vor, vor allem Zuhause, dass man an

    1. n verschiedenen Projekten arbeitet,
    2. die thematisch für m verschiedene Bereiche (Scopes) gedacht sind und
    3. die in k verschiedenen Programmiersprachen geschrieben werden,
    4. die unter j verschiedenen IDEs entwickelt werden.

    Wie strukturiert ihr das also?

    Die verschiedenen IDEs verlangen in der Regel ein default Workspacedirectory, in diesem werden die Projekte angelegt.
    Dazu kommt noch ein Config-Ordner der IDE selbst, in der sie weitere Metadaten, wie z.B. den Scope von Projekten speichert.
    Der Scope wird je nach IDE auch verschiedenen genannt, z.b. "Project Group" in Netbeans, "Session" in KDevelop usw.

    Eine Typische IDE hat also bspw. eine Ordnerstruktur (die Unterordner wie src und build lasse ich hier mal weg) wie folgende:

    A) // Ich setze mal zu jeder Ordneransicht einen Buchstaben hin, damit man darauf besser referenzieren kann

    |---workspace
    |---config
    |---Projekt_1
    |---Projekt_2
    |---Projekt_3
    |---Projekt_4
    |---Projekt_5

    In der IDE selbst könnte dann beispielhaft Projekt_1 und Projekt_4 zum Scope "Vereinsarbeiten" gehören und Projekt 2 und 3 zum Scope "Raspberry Pi".
    Und Projekt_5 arbeitet ihr grad an dem Code des ersten Kapitels eines neuen Programmierbuchs, dass ihr gerade gekauft habt.
    So, wenn ihr alles nur mit der gleichen IDE und Programmiersprache macht, dann könnte es das jetzt gewesen sein.

    Aber in der Praxis kommt dann vielleicht noch ein paar Projekte mit Python oder Java Code vor und dafür habt ihr eine andere IDE.
    Wie strukturiert ihr das jetzt?

    Gebt ihr für die beiden anderen IDEs das gleiche Workspacedirectory eurer ersten IDE an, so dass ihr alle Projekte unter einem Verzeichnis habt?
    Oder legt ihr für jede IDE einen separaten Ordner an, die dann jeweils als Workspacedirectory zählen?

    Beispielsweise so, wobei der Name workspace dann z.B. durch den Namen der IDE substituiert wird:

    😎

    |---eclipse
|   |---config
|   |---Projekt_1
|   |---Projekt_2
|   |---Projekt_3
|---netbeans
|   |---config
|   |---Projekt_1
|   |---Projekt_2
|   |---Projekt_3
|---vstudio
    |---config
    |---Projekt_1
    |---Projekt_2
    |---Projekt_3

    oder strukturiert ihr eure Projekte nach der Programmiersprache:

    C)

    |---cpp
|   |---config
|   |---Projekt_1
|   |---Projekt_2
|   |---Projekt_3
|---java
|   |---config
|   |---Projekt_1
|   |---Projekt_2
|   |---Projekt_3
|---python
    |---config
    |---Projekt_1
    |---Projekt_2
    |---Projekt_3

    oder macht ihr es ganz anders, und wählt dafür den scope:

    D)

    |---programmierbuch_xy
|   |---config
|   |---Projekt_1
|   |---Projekt_2
|   |---Projekt_3
|---raspberry_pi
|   |---config
|   |---Projekt_1
|   |---Projekt_2
|   |---Projekt_3
|---vereinsarbeiten
    |---config
    |---Projekt_1
    |---Projekt_2
    |---Projekt_3

    oder verschachelt ihr das noch weiter in:

    E)

    |---cpp
|   |---vereinsarbeiten
|       |---config
|       |---Projekt_1
|       |---Projekt_2
|       |---Projekt_3
|---java
|   |---programmierbuch_xy
|       |---config
|       |---Projekt_1
|       |---Projekt_2
|       |---Projekt_3
|---python
    |---raspberry_pi
        |---config
        |---Projekt_1
        |---Projekt_2
        |---Projekt_3

    Und was wenn ihr die gleiche IDE für zwei Sprachen verwendet?
    Sieht's dann bei euch eher so aus?

    F)

    |---eclipse
|   |---cpp
|   |   |---vereinsarbeiten
|   |       |---config
|   |       |---Projekt_1
|   |       |---Projekt_2
|   |       |---Projekt_3
|   |---java
|       |---programmierbuch_xy
|           |---config
|           |---Projekt_1
|           |---Projekt_2
|           |---Projekt_3
|---visual_studio_code
    |---python
        |---raspberry_pi
            |---config
            |---Projekt_1
            |---Projekt_2
            |---Projekt_3

    Oder doch eher so:

    G)

    |---cpp
|   |---eclipse
|       |---vereinsarbeiten
|           |---config
|           |---Projekt_1
|           |---Projekt_2
|           |---Projekt_3
|---java
|   |---eclipse
|       |---programmierbuch_xy
|           |---config
|           |---Projekt_1
|           |---Projekt_2
|           |---Projekt_3
|---python
    |---visual_studio_code
        |---raspberry_pi
            |---config
            |---Projekt_1
            |---Projekt_2
            |---Projekt_3

    Wobei ihr dann das Problem habt, dass ihr für die gleiche IDE zwei verschiedene Workspace Ordner habt, aber vielleicht installiert ihr die IDE zweimal, einmal für C++ und das andere mal für Java die dann ihren jeweiligen Workspace erhalten?
    Vielleicht setzt der ein oder andere noch symbolische Links, so dass einzelne Ordner in der Baumansicht mehrfach vorkommen?
    Oder ihr verwendet gar keine IDE und nur einen Texteditor (z.b. vim) für alles, wobei dann eine einfache Struktur wie A) leicht möglich ist.

    Ihr seht also, man kann das beliebig verschieden schachteln, wie habt ihr es gelöst?

    Mich würde mal interessieren wie ihr das macht.

    0
  • ?

    Noch etwas, in den Varianten E) und F) habt ihr dann übrigens noch das Problem, dass die IDE damit vielleicht nicht klar kommt, da sie erwartet, dass alle Projekte aller Scopes im gleichen Workspaceverzeichnis liegen.

    Wenn ihr also auf "New Project" klickt, dann besteht das Problem, dass ihr den Projektordner noch einmal separat anpassen müsst. Also auch unschön und fehleranfällige Mehrarbeit.

    Die ein oder andere IDE bietet dann vielleicht noch gar keinen Scope.
    Eclipse packt bspw. alle Projekte in eine einzige Project Explorer Ansicht und bietet meines Wissens nach keine Scope Ansicht in der IDE, wie es bspw. Netbeans ermöglicht.

    0
  • ?

    Eines habe ich noch vergessen.

    Vielleicht gehören Project 1 und 2 auch zusammen, weil ihr die mit git zusammen in ein git Repo schieben müsst.

    Dann wäre es doof, wenn die anderen Projektordner im gleichen Ordner liegen, weil dann git meckert.

    Oder noch schlimmer, ihr habt noch einen weiteren Projektordner, der ein eigenes git Repo hat.

    0
  • ?

    computertrolls schrieb:

    Die ein oder andere IDE bietet dann vielleicht noch gar keinen Scope.
    Eclipse packt bspw. alle Projekte in eine einzige Project Explorer Ansicht und bietet meines Wissens nach keine Scope Ansicht in der IDE, wie es bspw. Netbeans ermöglicht.

    Ich muss mich korrigieren.
    Bei Eclipse bilden die Workspaces den Scope ab.

    0
  • S

    Meine Projekte liegen alle auf D:\Development\<ProjectName>

    So viele sind's dann heutzutage nicht mehr, als dass ich da Unterordner benötige.

    MfG SideWinder

    0

  • Es ist für mich relativ klar, dass das Top-Level Kriterium das Projekt sein muss.
    Dabei ist ein Projekt eine eigenständige Einheit, die ich als ganzes irgendwoanders hin verschieben kann.
    Es kann natürlich externe Abhängigkeiten geben - aber die sind innerhalb des Projekts klar definiert, zB durch Pfadangaben in Umgebungsvaraiblen etc.. Hier werden Abhängigkeiten zu anderen (eigenen) Projekten nicht anders behandelt als Abhängigkeiten zu externen Libs zum Beispiel.

    Bei mir hab ich dann auch eine eindeutige Zuordnung von Projekt und SCM-Repository.
    Den Fall mit verschiedenen Repos im selben Projekt hab ich also vermieden.

    Ansonsten hab ich dann eher eine funktionelle Unterstruktur wie src-bin-lib-doc etc.
    Und da können auch unterschiedliche Sprachen in src zusammenstehen; evtl in weitere unter-Folder nach Unermodul gegliedert.

    Ich würde auf jeden Fall vermeiden mir irgendeine Folderstruktur von Sprache oder IDE aufzwingen zu lassen.
    Die Tools haben sich meiner funktionellen Gliederung anzupassen und nciht umgekehrt.
    Das gab auch nie irgendwie Probleme, ausser mit Eclipse, dessen bestehen auf den globalen Workspace mich immer total genervt hat. Wenn ich an einem Projekt arbeite möchte ich mit der IDE das Projekt öffnen (beschrieben durch eine Projektdatei mit den Metadaten), und nicht ein Verzeichnis.

    Es war dann noch die Frage, ob ich so Sachen wie vcproj-Projekt-Dateien im gleichen Verzeichnis wie die eigentlichen Sourcen haben will. Eigentlich nicht. Insbesondere wenn ich plattformübergreifen programmiere und auch auf anderen Systemem bauen will. Temporär aber ok, zb. wenn die vcproj von CMakefiles generiert werden und nicht slebst im Repo stehen.

    0
  • ?

    @scrontch

    Danke für deine Antwort, aber wie strukturierst du deine einzelnen Projekte, also nicht das, was in den Projektordern liegt, sondern die ganzen Projektordner als Ganzes?
    Ich habe die Überschrift etwas doof formuliert, das war eigentlich das was ich wissen wollte. Mein Fehler.

    0

  • äh, ich versteh die Frage glaub ich nicht.
    Ich hab zB.
    D:\Dev\Projekt1
    D:\Dev\Projekt2
    D:\Dev\Projekt3
    aber wenn da jetzt noch ein
    E:\Foo\Projekt4
    dazu kommt stört das die anderen herzlich wenig.

    0
  • ?

    Die Stören sich auch nicht, es ist mehr eine Strukturierung für einen selber.

    Man kann natürlich auch 100 Projektordner von 100 Projekten, die thematisch alle verschieden sind, von 15 verschiedenen Programmiersprachen in einem einzigen D:\Dev Ordner haben, aber ich finde, man muss sich darin ja auch noch zurecht finden können.
    Ich bevorzuge es daher meine Ordner zu strukturieren, siehe die Beispiele oben und suche nun dafür die beste Möglichkeit, bzw. ein paar Vorschläge dafür.

    Auch finde ich es hilfreich, wenn ich weiß, welches Projekt mit welcher IDE erstellt wurde, damit ich nicht unnötig die falsche IDE öffne, wenn ich ein bestimmtes Projekt bearbeiten will oder in einem Projektordner Dutzende Konfigurationsdateien von zig verschiedenen IDEs habe.
    Aus dem Grund kann es auch wichtig sein die Projekte nach der Programmiersprache zu strukturieren, da die oft auch die gewählte IDE bestimmt.

    Daher meine Frage.

    In den IDEs selbst helfen die Workspaces = "Project Groups" = Sessions zudem auch dabei, die Projekte thematisch zu strukturieren.
    Allerdings sind hier dabei nicht alle IDEs unabhängig vom Verzeichnis in dem die Projekte liegen.
    Weswegen es aus Dateisystemsicht Sinn machen kann, sich darüber ein paar Gedanken zu machen, wie man deren Root-Ordner als Ganzes im Dateisystem strukturiert.

    0
Anmelden zum Antworten