Dateien umbennen - welches Namensformat?

[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.

[Luckie]

Oft lasse ich das U dann auch weg: MpSysTools.pas.

[p80286]

Bei mir sieht es so aus:
MyProg.DPR
MyProg_.PAS {Main}
MyProgDM.pas {DataModule}
MyProgCSV.pas {Constanten,Typen,Variablen}
MyProgINI.pas {Initialisierung,Registry,IniFiles}

.....
AsciiDelim.Pas {csv}
Toolbox.Pas {utilities}

Gruß
K-H

[SneakyBagels]

Eine Art "Toolbox" hatte ich auch. Aber es gibt mittlerweile so viel Code dort drin, dass ich diese Datei aufteilen muss. So sind aktuell schon aus einer großen Datei etwa 15 kleine, thematisch sortiert geworden.

[himitsu]

Müsste es nicht MyProgCTV und MyProgIRI heißen?

Bei CSV und INI dachte ich erst an was ganz Anderes.

[SneakyBagels]

Das ist aber ein schönes Beispiel, dass es wohl keine Norm gibt und jeder sein eigenes System hat.

[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.