Delphi-PRAXiS - Unitnamen sinnvoll vergeben, aber wie?

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Projektplanung und -Management (https://www.delphipraxis.net/85-projektplanung-und-management/)

- - Unitnamen sinnvoll vergeben, aber wie? (https://www.delphipraxis.net/192403-unitnamen-sinnvoll-vergeben-aber-wie.html)

Unitnamen sinnvoll vergeben, aber wie?

Mein Projekt wird langsam immer größer. Es hat aktuell in etwa 80 eigene Units und Formulare.

Alle meine Formulare fangen mit frm an. Units mit immer und überall genutzten Funktionen und Prozeduren fangen mit _functions an, Threads fangen mit thread an.
Dann habe ich noch eine modifizierte TMemo- und TIni-Komponente. Beide Unitnamen fangen mit class an.
Units aus anderen Quellen, also nicht von mir, fangen mit u an.

Ich möchte da gerne etwas Ordnung reinbringen nur ich frage mich wie? Mein Benennungs-System am besten über Bord werfen oder nur anpassen?

AW: Unitnamen sinnvoll vergeben, aber wie?

Es gibt eigentlich kein vorgeschriebenes System.
Gut, viele nutzen erstmal U als Präfix, damit kann man Unit (UXyz), Klasse (TXyz) und, bei Forms/Modulen, die globale Variable (Xyz) gleich zu benennen.

Viele haben ein Frm, Form oder der Gleichen bei Formularen davor.
Ich persönlich mach sowas nicht mehr. Entweder im Unitnamen steckt nicht drin, dass es eine Form ist,
oder fasse es über einen Namespace zusammen, wenn es mehrere zusammengehörende Units gibt. (so ala abc.def.consts.pas, abc.def.utils.pas und abc.def.form.pas)

Bei Komponenten hab ich mir ein einen eigenen Namespace zugelegt
und eventuell noch einen Zweiten, wenn die Unit zu einer größeren Projektgruppe gehört.
Quasi wie das VCL.xxx.pas, FMX.xxx.pas und System.xxx.pas vom Delphi.
So kann ich dann meine Hilfsfunktionen auch einem ähnlichen Namensschema unterziehen. (Xyz.StrUtils.pas)
Damit das Präfix nicht zu lang wird, nutze ich allerdings ein Numeronym ala l10n=localization oder i18n=internationalization.

AW: Unitnamen sinnvoll vergeben, aber wie?

Bei uns ist das sehr einfach:
Zunächst wird getrennt zwischen den Projekten.

Common.* --> Gemeinsame Units für mehrere Projekte (allgemeine Tools, ...)
Frontend.* --> Dateien unseres Frontends
Backend.* --> Dateien unseres Backends

Und dann wird nach Funktionalität unterschieden:

Common.Dialog.* --> Formulare
Common.Gui.* --> Oberflächenspezifische Units
Common.Hardware.* --> Units zur Hardwareunterstützung
Common.Interfaces.Core.* -->Interfaces zu Klassen in den Core-Units
Common.Interfaces.Gui.* --> Interfaces zu den Gui-Klassen
Common.Core.* --> Kernunits des Projekts

Und so weiter...

Die entsprechenden Punkte bezeichnen auch die Verzeichnisse (z.B. Repository\Common\Interfaces\Gui\Common.Interfaces .Gui.GuiElement.pas für das Interface IGuiElement). So lässt sich eine bestimmte Unit auch sofort auf der Festplatte finden.

Das Vorgehen hat auch den Vorteil, dass die Unit immer genauso wie die Klasse oder das Interface heißt. Ich kann also in der uses-Klausel z.B. ComIntGuiElem schreiben (nur zur Verdeutlichung mit Großbuchstaben) und die CnWizards werden mir die passende Unit Common.Interfaces.Gui.GuiElement vorschlagen.

Deshalb müssen wir nie lange suchen, das spart enorm Zeit.

Und ganz wichtig:
Nie unnötig abkürzen... das verringert nur die Lesbarkeit. Das gilt für Unitnamen wie für Variablen usw.
Schreibfaul sollte man beim Programmieren nicht sein, zumal die CnWizards da extrem viel Tipparbeit abnehmen... wenn man denn seine Bezeichner gut gewählt hat.