Dateien umbennen - welches Namensformat?

[SneakyBagels]

Zitat:

TStringUtils -> Unit: SneakyBagels.StringUtils

Ist das tatsächlich ein gebräuchliches Format?
Was könnte man denn noch außer den Benutzernamen nehmen? Der Programmname wäre m.E. nicht so pralle
Vielleicht die ersten beiden Initialen meines Programmnamens?

[Uwe Raabe]

Zitat von SneakyBagels:

Was könnte man denn noch außer den Benutzernamen nehmen? Der Programmname wäre m.E. nicht so pralle

Wieso nicht? In einigen Projekten verwende ich das genau für die projektspezifischen Units. Das ist insbesondere hilfreich, wenn mehrere Projekte zu einer Projektgruppe gehören, die UNits mit ähnlicher Funktionalität haben, aber eben nicht gleich sind.

MyProject1.Utilities.pas, MyProject2.Utilities.pas,...

[SneakyBagels]

Eine Frage bleibt noch... wie würde ich denn die ganzen Utils-Units ordentlich und nacheinander sortiert bekommen?
<Programmname>.StringUtils.pas, <Programmname>.DateUtils.pas da sist ja OK. Aber alphabetisch sortiert werden kann das schlecht =/
<Programmname>.Utils.Strings.pas ist nicht so toll oder?

[Der schöne Günther]

Zitat von SneakyBagels:

<Programmname>.Utils.Strings.pas ist nicht so toll oder?

Für mich wäre das ganz nach meinem Geschmack

Wenn es sich lohnt, warum nicht? In unserer Lieblings-Entwicklungsumgebung ist das ja auch...

Code:

System.Classes.pas

System.Generics.Collections.pas
System.Generics.Defaults.pas

System.JSON.pas
System.JSON.Writers.pas
System.JSON.Types.pas

[SneakyBagels]

Dann werde ich mich heute Abend mal daran machen und alles vernünftig umbenennen. Habe eben schon ein paar Units so angepasst, dass ich folgendes Konstrukt im Kopf habe:

Delphi-Quellcode:

unit ab.Utils.Strings;

interface

uses ... ;

// ------------------------------------------
type
 TStringUtils = record
 private
  //
 public
  class procedure test; static;
 end;
// ------------------------------------------

implementation

class procedure TStringUtils.test;
begin
end;

end.

Alles zwischen // ------ baue ich grundsätzlich in alle meine Units ein.

Ich würde es sehr begrüßen, wenn die IDE ein bisschen moderner wäre. Man siehe sich nur den Solution-Explorer in VisualStudio an.
Bei Delphi funktioniert ja nicht einmal Unit markieren => F2

MeinKürzel.EineGruppe.DieFunktion.FMX.pas
Wenn ich STRG gedrückt halte, muss ich dann zu MeinKürzel oder EineGruppe springen können? Denn das hier ist ja nur eine einzige Datei und man könnte in diesem Falle nur zu FMX springen.

[Luckie]

Ich setze immer noch mein Namenskürzel davor: MpUSysTools.pas, wenn es sich nicht um Projekt spezifische Units handelt. Ansonsten heißt die Unit wie die darin enthaltene Klasse nur mit einem "U" davor. Units mit Formularen beginnen mit "frmBlablaDialog.pas" und die Unit des Hauptformulares heißt einfach Main.pas.

[Der schöne Günther]

Vielleicht habe ich eine Leseschwäche, vielleicht bin ich verweichlicht, aber vor allem im ersten Fall sehe ich nur Suchbabenstalat und brauche drei Anläufe um zu entziffern was gemeint ist.

[himitsu]

Zitat von SneakyBagels:

<Programmname>.Utils.Strings.pas

Bei mir haben Units auch mindestens 2 bis 3 Ebenen.

MeinKürzel.DieFunktion.pas
MeinKürzel.EineGruppe.DieFunktion.pas

"MeinKürzel" für Komponenten/GemeinsameUnits und "ProjektName" für das jeweilige Projekt.


Man muß auch nicht unbedingt name.space verwenden, denn unser_score oder CamelCase ist auch weit verbreitet, aber so passt es sich in die Unitnamen des Delphi ein und man kann auch mal mit DefaultNamespaces arbeiten.
VCL.MeinKürzel.EineGruppe.DieFunktion.pas
FMX.MeinKürzel.EineGruppe.DieFunktion.pas

Im Programm nimmt man dann nur noch MeinKürzel.EineGruppe.DieFunktion und Delphi nimmt die Unit des verwendeten GUI-Systems.

Wobei es mir eigentlich besser gefallen würde, wenn es so hieße
MeinKürzel.EineGruppe.DieFunktion.VCL.pas
MeinKürzel.EineGruppe.DieFunktion.FMX.pas

[SneakyBagels]

Hier noch eine weitere Möglichkeit von Herr Jaenike

Zitat:

// EDIT:
Nebenbei, falls die Unitnamen echt sind:
Unterstriche in Unitnamen und Bezeichnern sind in Delphi unüblich. In Delphi ist CamelCase üblich und für Unitnamen auch Punkte. (Empfinde ich auch als deutlich besser lesbar.)
Bei uns würden die Units z.B. heißen (wenn es allgemeine Units für mehrere Projekte sind, daher Common):
Common.Utils.Logging.pas, Common.Types.Logging.pas, ... (Im Unterverzeichnis common\utils bzw. common\types)
Und so allgemeine Namen wie _globals oder so würde es bei uns nicht geben, da das nichts über die Funktion aussagt. Die Klasse hieße bei uns dann auch z.B. TLogging und wäre die einzige in der Unit.
Auf die Weise werden auch die Units nicht so groß und übersichtlich und man findet auch direkt die Units zu den Klassen.

Hierzu eine Frage:
Common steht hier wohl vermutlich dafür, dass die Unit nur in diesem einen Project verwendet wird.
Wird für eine Unit, die in mehreren Projekten verwendet wird, demnach Shared verwendet?

Angenommen ich habe eine Unit Utils.Logging.pas - was käme dann da rein?
Und was in Types.Logging.pas?

Sehe ich das richtig, dass in erste Unit der Log-Code ansich kommt und in letzte zum Beispiel Records, Classes, Enums?
Aktuell habe ich es so, dass ich alle meine Enums in einer einzigen Unit drin habe.

[jaenicke]

Zitat von SneakyBagels:

Common steht hier wohl vermutlich dafür, dass die Unit nur in diesem einen Project verwendet wird.

Wir haben diese Struktur:
Projekt.Kategorie.(Untergruppe.)Unitname.pas
bzw. für Interfaces:
Projekt.Interfaces.Kategorie.(Untergruppe.)Unitnam e.pas

Auf die Weise werden die Namen nicht zu lang, sind aber dennoch eindeutig. Projekte sind bei uns so etwas wie Server, Frontend, Backend usw. sowie bei gemeinsamen Units Common. Kategorien sind z.B. Network, Encryption, Hardware, ...
Untergruppen sind optional und kaum benutzt (die Unitnamen werden damit halt schon recht lang).

Die Unit heißt immer genauso wie das Interface oder die Klasse, die sich darin hauptsächlich befindet. Es sollte auch nichts zusätzlich drin sein, das nicht direkt dazu gehört.

Und jeder Punkt ist auf der Festplatte ein Pfadtrennzeichen, sprich es liegen auch nicht so viele Units in einem Verzeichnis, man findet die Units aber dennoch leicht und für Skriptzugriffe auch automatisiert.

Beispiel:
IPrinter wäre in Common.Interfaces.Hardware.Printer.pas definiert, TEpsonPrinter z.B. in Common.Hardware.EpsonPrinter.pas.

Mit Tools wie den CnWizards, die die Syntaxergänzung erweitern, so dass die Printer-Unit auch mit der Eingabe "ComIntHarPri" (kleingeschrieben, nur zur Verdeutlichung) gefunden wird, sind natürlich sehr hilfreich um weniger tippen zu müssen.

Zitat von SneakyBagels:

Sehe ich das richtig, dass in erste Unit der Log-Code ansich kommt und in letzte zum Beispiel Records, Classes, Enums?
Aktuell habe ich es so, dass ich alle meine Enums in einer einzigen Unit drin habe.

Wir machen das aus mehreren Gründen nicht so.
Der wichtigste ist, dass man so Funktionalität auf mehrere Units verteilt und so bei Änderungen an größeren Units etwas ändert, an denen dann öfter Änderungen für verschiedene Teile der Anwendungen passieren. Das macht es nicht einfacher Änderungen nachzuverfolgen und zu mergen.

Gemeinsam genutzte Typen wie TColor in System.UITypes deklarieren wir natürlich auch zentral.

Dazu kommt, dass man nicht nur die Unit in die uses kleben muss, die die Funktionalität enthält, sondern zusätzlich noch z.B. eine für Enums usw.
Sind die Typdefinitionen direkt in der Unit mit dem Interface, sind diese bereits direkt bekannt. Man muss also nicht erst suchen wo der Rest definiert ist. Das macht die Verwendung deutlich einfacher.