Projektstruktur (nicht alles in einem Ordner)

[Rollo62]

Ich bin nicht sicher ob diese "Namespaces" mit '.' auch unter Lazarus und FPC funktionieren.
Meiner Meinung nach war das mal ein Problem, habs nie gecheckt.

Ach ja, "Namespaces" sind ja eigentlich mehr als nur '.' Bezeichnungen.
Trotzdem wissen hoffentlich Alle wie es gemeint ist.

@bernau
Ich nutze auch gerne externe Tools statt dem Grep in der IDE.
Das ist mir sowieso etwas zu beschränkt.


Also bis jetzt spricht erstmal nichts Grundsätzliches gegen die mehr flache Lösung,
da bin ich aber froh

[Delphi.Narium]

Statt . kann man ja auch den _ nehmen. Funktioniert bei meinem ollen Delphi 7 schon seit ewig und drei Tagen.

Neue Delphis kommen damit auch klar und FreePascal bestimmt auch.

Und ob die optische Trennung nun durch . oder _ erfolgt, sollte nur ein bisserl Gewohnheitssache sein. Dürfte aber letztlich gleich gut zu unterscheiden sein.

Alles was nur zu einem Projekt gehört, liegt bei mir im Projektverzeichnis.

Für Komponenten, die "überall" gebraucht werden können, gibt es ein Verzeichnis Komponenten. Fremdkomponenten erhalten dort ein Unterverzeichnis mit ihrem Namen. JCL, JVCL ...

Für Frames gibt es eine Verzechnis Frames, in das halt alle Units kommen, die in unterschiedlichen Projekten genutzt werden und Frames enthalten.

Units mit diversen "Hilfroutinen" sind im Verzeichnis Tools. Vom Aufgabengebiet her zusammengehörende Hilfsroutinen kommen in eine Unit für dieses Aufgabengebiet. Ist also alles schön sachlich sortiert.

Jedes Projekt hat sein eigenes Projektverzeichnis.

In der Regel sind die Projekte so konfiguriert, dass sie alle die DCUs in das gleiche Verzeichnis schreiben, kompilierte Packages kommen auch in ein Verzeichnis, dito Exen.

Alles liegt auf einem Laufwerk in 'nem Verzeichnis Delphi.

Code:

Laufwerk:
  Delphi
    _bpl
    _dcu
    _exe
    Komponenten
      JCL
        und hier halt die Struktur der JCL
      JVCL
        und hier halt die Struktur der JVCL
      ...          
    Frames
    Tools
    Je Projekt ein Verzeichnis

Für mich ist das in punkto Übersichtlichkeit ausreichend.

Damit Delphi beim Kompilieren nicht so ewiglange suchen muss und die Suchpfade nicht unübersichtlich groß werden, werden alle benötigten Dateien ins Projekt aufgenommen. Gut: Die DPR kann dann schonmal was länger werden, aber da muss man für gewöhnlich eh nicht ran, kann aber in der Projektverwaltung recht schnell sehen was man so alles ins Projekt eingebunden hat und die Dateien schnell in der IDE zur Bearbeitung öffnen.

[himitsu]

Die Pseudo-Namespaces mit . im Dateinamen haben noch den Vorteil, dass man dort Defaultnamespaces als Prefix verwenden kann.
Mir wäre von der Struktur im Verzeichnis es lieber, wenn man die auch als Postfix nutzen könnte.

Wird z.B. für VCL oder FMX verwendet
> Forms -> VCL.Forms oder FMX.Forms
oder für dein "einfachen" Umstieg bei altem Code.
> Windows -> Winapi.Windows
> Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell



My.Unit ins Uses schreiben und je nach Ziel wird das verwendet
My.Unit.Windows
My.Unit.iOS
My.Unit.Linux

So geht es, aber es ist sch***
Windows.My.Unit
iOS.My.Unit
Linux.My.Unit

[Rollo62]

@himitsu

Verstehe nicht genau was Du meinst,
sollte etwa das hier

My.Unit ins Uses schreiben und je nach Ziel wird das verwendet
My.Unit.Windows
My.Unit.iOS
My.Unit.Linux

sich das richtige Unit raussuchen, je nach OS, ohne {$IF} ?

Meinst Du das sowas jetzt schon in Delphi irgendwie geht, neee, das kann doch nicht sein, oder ?

Falls doch wäre das natürlich super.

Ich nutze auch Postfixes, aber noch mehr als nur FMX/VCL.
Vorne steht bei mir die Funktion, also das was ich erstmal eigentlich will,
weiter nach hinten kommen dann die Spezialisierungen.
Media.Audio.Play
Media.Audio.Play.Win
Media.Audio.Play.Macos
Media.Audio.Rec
Media.Audio.Rec.Win
Media.Audio.Rec.Macos

notfalls kann ich dahinter dann noch das Framework schreiben FMX/VCL
Media.Audio.Play
Media.Audio.Play.Win.VCL
Media.Audio.Play.Win.FMX
Media.Audio.Play.Macos.FMX
Media.Audio.Rec
Media.Audio.Rec.Win.VCL
Media.Audio.Rec.Win.FMX
Media.Audio.Rec.Macos.FMX

das ist aber meist schon überflüssig (z.B. weil Macos i.d.R. nur FMX sein kann ).
Ok, jetzt lassen wir mal CrossVCL, TMS WebCore, FNC, ... aussen vor

Wichtig finde ich bei der Nomenklatur dass das eigentlich Entscheidende, die Funktion, vorne steht:

Media.Audio.Play

Das mag Vielen wie umgekehrt polnische Notation vorkommen, ist aber in der Praxis sehr hilfreich.
(und UPN war der normalen Notation logisch überlegen, auch wenn ich es damals sehr gehasst habe ).

[himitsu]

Projektoptionen > Erzeugen > Delphi-Compiler : Unit-Gültigkeitsnamen

Da in der Mitte des langen Textes versteckt sich standardmäßig ein ;Vcl; bei neuen VCL-Projekten
und ;Fmx; bei den geräteübergreifenden Projekten.
(beim Upgreade alter Projektdateien wird das aber nicht automatisch eingefügt, drum heißt es dann gern "Unit Forms nicht gefunden")

Dadurch wird beim Kompilieren, wenn eine Unit MyUnit nicht gefunden wird, entsprechend auch nach Vcl.MyUnit oder Fmx.MyUnit gesucht,
drum kannst du uses Forms; schreiben und kompiliert wird mit Vcl.Forms , bei einem VCL-Projekt.


Dort kann man auch Eigenes einfügen, für eigene/fremde Bibliotheken.



Für Bibliotheks-Präfix funktioniert das super,
aber von der Sortierung im Verzeichnis und für die Codevervollständigung, wäre es als Platform-Suffix übersichtlicher.

Zitat:

notfalls kann ich dahinter dann noch das Framework schreiben FMX/VCL

Genau, man kann muss es hinschreiben, aber automatisch geht es nicht, jedenfalls nicht hinten.

[Rollo62]

@himitsu
Aha, man lernt nie aus.
Ich denke man könnte sich alleine 1 Jahr mit der IDE un deren versteckten Funktionen beschäftigen.