Präfix oder Suffix - Wie haltet Ihr es mit der Namensgebung?

[Sherlock]

Es gibt da ja im Borland Styleguide edn.embarcadero.com/article/10280 (ja Borland. Da steht zwar irgendwo im Link Embarcadero, aber im weiteren Verlauf wird so oft der Name Borland genannt, daß man vor Rührung heulen möchte) den Abschnitt zur Namenskonvention. Interessanterweise gibt es dort keinen Hinweis auf die Notwendigkeit von Typangaben bei Bezeichnern - weder Prä noch Suff werden da gefordert. Im Prinzip haben die ja sogar Recht, da entwickelt man endlich nicht mehr in einem Texteditor, sondern in einer IDE mit so mächtigen Dingen wie Tooltips, die einem im Nullkommanix den Typ und den Ort der Deklaration anzeigen können, da ist ein wie auch immer gearteter -fix nicht mehr nötig. Nun ist der Mensch aber ein Gewohnheitstier, was früher unter Fortran gut und richtig wahr, ist auch heute noch gültig. Darum bemüht man sich um schöne Bezeichner, die den Typ wiedergeben sollen.

Hier nun zum Kern: Am beliebtesten scheint aktuell der Präfix zu sein. Wenn man also ein TEdit hat, das erlaubt einen Vornamen einzugeben, wird das Ding in der Regel (Abkürzungen machen das Leben leichter)

Delphi-Quellcode:

EdVorname

genannt. Für ein Label zu eben diesem Edit folgt demnach

Delphi-Quellcode:

LblVorname

.

Es gibt aber auch die andere Möglichkeit, nämlich den Typen ans Ende zu setzen. Es gäbe dann also ein

Delphi-Quellcode:

VornamenEd

und ein

Delphi-Quellcode:

VornamenLbl

(Man beachte die Grammatik).

Meine Präferenz geht klar zu letzterem, wobei ich aber Basistypen wir Integer, String oder Boolean weglasse. Das ist nun wirklich entweder dem sinnvollen Namen oder auch besagtem Tooltip zu entnehmen. Ich würde also nur bei komplexen Objekten ein Typensuffix verwenden. Zusätzlich würde ich den Suffix nicht abkürzen, sondern ausschreiben - bevorzugt jedoch den einfachen Vorfahren (statt

Delphi-Quellcode:

BerufsDBLookUpComboBox

lieber

Delphi-Quellcode:

BerufsCombo

).

Wie haltet Ihr das also mit der Namenskonvention?

Sherlock

[Der schöne Günther]

Meinst du

1. Die Benennung von Komponenten auf VCL/FMX-Formularen
2. Die allgemeine Namensgebung für alle Bezeichner?

Ich bekomme Ausschlag wenn ich sehe wie manche Leute in Pascal ihre Bezeichner dekorieren. Meine Weltanschauung sagt:

• A vor Parametern ("Argument"): NEIN.
• L vor lokalen Variablen: NEIN.
• T vor Typbezeichnern ("TObject"): Ja, denn Pascal ist leider case-insensitiv.
• P vor Pointer-Typen: Ja. Wahrscheinlich C-Angewohnheit, denn dort ist vieles weniger typsicher. In Delphi könnte man sich das wohl in 90% aller Fälle sparen
• I vor Interface-Typen. Ja. In C# ist es auch so, ist glaube ich einfach nur ein Microsoft-Stil. Woanders habe ich so etwas nämlich noch nie gesehen.
• F vor Klassen/Record-Feldern. Jein. Ich hasse es wie die Pest. Hat man aber eine gleichnamige Property geht es nicht anders. Wäre Pascal case-sensitiv würde ich es über Groß/Kleinschreibung machen (Property groß).
• Statische Methoden: Anfangsbuchstabe groß. Instanzmethoden: Anfangsbuchstabe klein. Meine einzige Hilfe- Ich komme bis heute nicht damit zurecht, wie man in Delphi sonst vernünftig erkennen kann ob eine Methode statisch ist oder nicht!

Zu Komponenten auf Formularen: Ich packe den Typen auch immer in den Namen, allerdings am Schluss. Was bringt es wenn er am Anfang steht? Vor allem so komisch abgekürzt? Ich sehe nicht wo ein "btnStartSomething" besser und leserlicher ist als ein "startSomethingButton". Vor allem weil sich jeder für jede Komponente wahrscheinlich eigene Abkürzungen erfindet...

[Sir Rufo]

Ich verwende immer den Typen als Suffix.

Delphi-Quellcode:

KundeIdLabel: TLabel;
KundeNummerEdit: TEdit;
KundeNameEdit: TEdit;
LieferantIdLabel: TLabel;
LieferantNummerEdit: TEdit;
KundeEditForm: TForm;

Meine Denkweise ist eben einfach so, dass ich z.B. vom Lieferent die Nummer irgendwo hinschreiben möchte und dann sehe ich duch CC sofort, aha ein Edit/Label.

• LieferantNummerEdit
• LieferantNummerEdit
• LieferantNummerEdit

Und weil der Typ am Ende steht, habe ich auch sofort die Assoziation zum Typen und weiß, was ich dort an Eigenschaften und Methoden erwarten kann.

[Luckie]

Ich bevorzuge Präfixen. Und der Typ ergibt sich aus der Benennung:

PersonalNummer -> Integer
PersonalName -> String
IstKrank -> Boolean

Und bei den heutigen modernen IDs mit Codevervollständigung machen Typen in der Benennung den Code nur unübersichtlicher. In den 70'ern mit C und typenunsicheren Sprachen war es wohl mal sinnvoll. heute sehe ich keine Notwendigkeit dazu. Und du hast ja selbst gesagt, dass da immer der Name Borland auftaucht, da kannst du schon sehen, wie alt das Dokument ist.

[MichaelT]

Prefix - Sortierung frei Haus.

Zitat:

Zitat von Sherlock (Beitrag 1310099)

Wie haltet Ihr das also mit der Namenskonvention?

Sherlock

[Mavarik]

Typen immer dahinter...

TEdit
VornameEdit
TelefonEdit1
TelefonEdit2

TLabel
VornameLBL
TelefonLBL1

TButton ohne type sondern Funktion die er auslößt.
SucheStarten

TTabControl
BilderTab

Bei Variablen die "A","L","T","P","I","F" Prefix-Geschichte

Mavarik

[TRomano]

Ich benutze immer Präfixe ... alte Angewohnheit aus den 80'ern (warum weiß ich nicht mehr).
Bei Typen, Zeigern halte ich mich an Delphi, also vorangestelltes "T" oder "P".

bei Komponenten:

cbCheck : Checkbox
dbeFirstName: DBEdit
rgChoice : RadioGroup
dictNamen : Dictionary
usw.

Nur bei einigen anderen Komponenten bin ich da ein wenig lascher ... alle Arten von Listen bekommen ein "lst" vorangestellt.

Gruß Thomas

[stahli]

Bei Variablen benutze ich die klassischen Präfixe (z.B. fName, aName, lName). Die Kleinschreibung finde ich dabei hilfreich.

Listenvariablen hänge ich meist nur List an, auch wenn das grammatikalisch nicht ganz sauber ist (z.B. PersonList statt People oder CityList statt Cities).

Klassen und Interfaces gebe ich auch gerne mal ein Präfix, damit die Zugehörigkeit zu einer Gruppe schnell klar wird (z.B. TxyClass bzw. IxyIntf).


Formularcontrols benenne ich in der Form EditPersonFirstname, wenn es notwendig ist.

Wenn man ein Framework hat/hätte, das ein konsequentes Databinding unterstützt, müssten Formularcontrols eigentlich gar nicht mehr benannt werden. Dann müssten die Controls eigentlich nicht mehr mit Namen angesprochen sondern nur noch an bestimmte Daten gebunden werden.

[MichaelT]

a ... ist durchaus nicht ungewöhnlich - ein unbestimmter Artikel oder unbest. Zahlwörter. (a, some, ..)

Das mit dem l hat heute keine Bedeutung mehr. Die Methoden viel kürzer sind als noch vor geraumer Zeit. Der Vorteil ist beim Suchen sieht man die Zuweisungen. Bei prozeduralen Sprachen (PL-SQL oder ABAP) ist das vorteilhaft - Verbundtypen. Bei mir blieb auch nurmehr lWork ... das sind beliebige Verbundtypen außer Klassen eben instanziert, alles was so an 'record' erinnert.

Zitat:

Zitat von Der schöne Günther (Beitrag 1310102)

Ich bekomme Ausschlag wenn ich sehe wie manche Leute in Pascal ihre Bezeichner dekorieren. Meine Weltanschauung sagt:
[LIST][*]A vor Parametern ("Argument"): NEIN.[*]L vor lokalen Variablen: NEIN.

[bernau]

Ich benutze immer Präfixe. Weil es schon immer so war. :roll:

Bei Komponenten:

EdVorname:TEdit
ChkIstBlond:TCheckbox
LbOrte:TListbox

etc.


Argumente beginnen immer mit "a".
Lokale Variablen immer mit "l".

u.s.w.


Ich mag es, wenn ich in der Klasse sortieren kann und alle Edits beisammen habe.

[frankyboy1974]

Hallo,

ich programmiere in Delphi wie in Java, also mit Framework Richtung GUI.
Komponenten haben gar keinen Namen (zumindestens für mich nicht), und schreiben die Eingabe nur in das entsprechende Model. Nachdem ich eine GUI-Komponente auf den Bildschirm gepackt habe, funktioniert diese so wie alle anderen.:roll:
Danach kann ich keine GUI-Komponente mit ihrem Namen ansprechen, wenn ich eine implizite Änderung haben möchte, geht dies nur über das Model.

mfg

Frank

[Mavarik]

Zitat:

Zitat von MichaelT (Beitrag 1310124)

Das mit dem l hat heute keine Bedeutung mehr. Die Methoden viel kürzer sind als noch vor geraumer Zeit. Der Vorteil ist beim Suchen sieht man die Zuweisungen. Bei prozeduralen Sprachen (PL-SQL oder ABAP) ist das vorteilhaft - Verbundtypen. Bei mir blieb auch nurmehr lWork ... das sind beliebige Verbundtypen außer Klassen eben instanziert, alles was so an 'record' erinnert.

Delphi-Quellcode:

... // Einige Zeilen Source 

LWert := AWert; // Ah OK wurde an die Procedure übergeben und nur lokal gespeichert...
FWert := AWert; // Ah OK wurde an die Procedure übergeben und wird in der Klasse / Im Record gespeichert

Nummer := Wert; // sagt überhaupt nix aus

if IWert <> NIL then // Muss ein Interface sein...

PSource := AText; // Auch klar

Also sehr sinnvoll...

[p80286]

Zitat:

Zitat von Luckie (Beitrag 1310111)

Ich bevorzuge Präfixen. Und der Typ ergibt sich aus der Benennung:

PersonalNummer -> Integer
PersonalName -> String
IstKrank -> Boolean

ist dieser Blödsinn, denn nicht auszurotten?
Die Personalnummer ist nicht numerisch! Es ist eine Aneinanderreihung von Ziffern, damit wird nicht gerechnet, und führende Nullen gehören dazu!
(vllt. wäre es besser von Personalkennung zu reden)
Immer wieder schön wenn Excel Personalnummern als numerische Werte sortiert, und dann jemand aufgeregt über die Flure läuft "der X ist nicht mehr bei uns!"

Gruß
K-H

[Daniel]

Ich denke, dass es Michael um die Namensgebung ging.
Eine Variable endet bei ihm auf "Nummer" und ist folglich numerisch, endet sie auf "Name" kann man einen String vermuten und Dinge, die mit "Ist" beginnen, scheinen boolsche Flags zu sein.

Um den Aufbau von Personalnummern und deren Behandlung ging es Michael mutmaßlich nicht.

[mquadrat]

Bei der Personalnummer finde ich es nicht so schlimm (bei einigen Firmen sind die Dinger tatsächlich numerisch [also ohne führende Nullen]). PLZ als integer ist viel lustiger :-)

Zum Thema:
Komponenten werden gepräfixt, weil war schon immer so. Bei Forms, die per Convention over Configuration automatisch gebunden werden, haben dann natürlich kein Präfixe bei den Komponenten. Private Attribute in den Klassen kriegen bei uns einen _ statt einem f. Haben wir auch mal von irgendwo übernommen.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1310102)

Zu Komponenten auf Formularen: Ich packe den Typen auch immer in den Namen, allerdings am Schluss. Was bringt es wenn er am Anfang steht? Vor allem so komisch abgekürzt? Ich sehe nicht wo ein "btnStartSomething" besser und leserlicher ist als ein "startSomethingButton". Vor allem weil sich jeder für jede Komponente wahrscheinlich eigene Abkürzungen erfindet...

Schlicht weil es so sehr viel einfacher ist eine bestimmte Komponente anzusprechen. Wenn ich ein Label suche, schreibe ich lbl, und in der Regel finde ich es dann über die Syntaxergänzung direkt über den Namen ohne auf das Formular schauen zu müssen.

Außerdem gibt es dann ein lblItemName und ein edtItemName, d.h. die Beschriftungslabels können abgesehen vom Typ genauso heißen.
Bei Variablen macht die ungarische Notation in Delphi aber keinen Sinn.

Ansonsten mache ich es etwas anders als du:

• A vor Parametern ("Argument"): Ja, denn so können diese genauso wie Properties der Klasse heißen ohne dass der Name exakt gleich ist.
• L vor lokalen Variablen: Nein, denn wer so lange Methoden hat, dass man das braucht, der hat ganz andere Probleme...
• F vor Klassen/Record-Feldern: Mache ich immer so, denn abgesehen davon, dass es Konvention ist, ist es sehr praktisch für die Übersicht. Und ich kann immer ein F schreiben und bekomme alle privaten Felder. Denn nur dort gehört das F hin, nicht vor alle Felder.

Zitat:

Zitat von Der schöne Günther (Beitrag 1310102)

P vor Pointer-Typen: Ja. Wahrscheinlich C-Angewohnheit, denn dort ist vieles weniger typsicher. In Delphi könnte man sich das wohl in 90% aller Fälle sparen

Naja, es ist schon praktisch, wenn ich einen Typ TExample habe, dazu einen Pointertyp PExample und eine Variable Example. ;-)
Sich da jedesmal krampfhaft etwas auszudenken hielte ich für deutlich weniger schön.

Zitat:

Zitat von Der schöne Günther (Beitrag 1310102)

Statische Methoden: Anfangsbuchstabe groß. Instanzmethoden: Anfangsbuchstabe klein. Meine einzige Hilfe- Ich komme bis heute nicht damit zurecht, wie man in Delphi sonst vernünftig erkennen kann ob eine Methode statisch ist oder nicht!

Für solche Sachen gibt es ja den Code Explorer, das sieht man dort glaube ich auch sofort:
http://www.modelmakertools.com/code-explorer/index.html

Zitat:

Zitat von Der schöne Günther (Beitrag 1310102)

Ich bekomme Ausschlag wenn ich sehe wie manche Leute in Pascal ihre Bezeichner dekorieren.

Ich halte mich an den Styleguide und an die Konventionen. Das finde ich besser als sich eigene Regeln auszudenken, die dann von jedem fremden Quelltext abweichen (z.B. eben, wenn du kein F vor privaten Felder nutzt).

[Dejan Vu]

Ich finde, wenn ich im Code kodieren muss, woher meine Werte kommen oder wo sie liegen ('L', 'A', 'F'), dann ist mein Implementierung zu kompliziert. Meine Methoden haben maximal 7, in Ausnahmefällen auch mal 10 Zeilen, zuzüglich 1-3 Zeilen Deklaration lokaler Variablen). Da muss ich nichts zusätzlich kodieren: Ich sehe doch auf den ersten Blick, was 'FooBar' für ein Ding ist.

Allerdings geht Konvention und Standard (welcher, ist egal), über alles. Wenn es also üblich ist, die Typen, Interfaces und Felder mit dem entsprechenden Präfix zu versehen, mache ich da mit. Es tut nicht weh und man muss sich nicht ständig erklären.

Was die VCL-Steuerelemente anbelangt, habe ich jahrelang 'ed', 'lb', 'cb' etc. verwendet. Bis ich gemerkt habe, wie überflüssig das ist. Während ich sonst auf Lesbarkeit (Clean Code) allergrößten Wert lege, schlampe ich dafür bei den Control-Namen? "Wie blöd ist das denn?" habe ich mir gedacht. Und wenn ich mir schon überlegen muss, ob welchem Namen ich einem Control verpasse (edName? NameEingabe? NameEdit?) verwende ich vermutlich eh zu viel Logik im UI-Code.

Im Idealfall (Binding), verwende ich die Controls überhaupt nicht im Code. Alles ist in der DFM und da ist es auch wurscht, wie die Controls heißen. Aber klar, manchmal muss man tricksen, aber eigentlich fast ausschließlich in Eventhandlern. Und da kommt das Control in Form eines 'Sender' und kann auf eine klar benannte lokale Variable gecastet werden.

Nur in seltenen Fällen würde ich einem Control einen Namen verpassen. Aber dann ohne erklärenden Prefix (oder Suffix), denn im Namen soll idealerweise die Implementierung *nicht* vorkommen.

Edit: Habe gerade bemerkt, das sich meine Ansichten mit der von Sebastian (Jaenicke) ziemlich genau decken...

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1310165)

Meine Methoden haben maximal 7, in Ausnahmefällen auch mal 10 Zeilen, zuzüglich 1-3 Zeilen Deklaration lokaler Variablen).

Die Software möchte ich mal sehen... Kann ja nur ein Call nach dem anderen sein... :idea:

[Dejan Vu]

Mavarik, lies einfach mal das Buch 'Clean Code' oder schau dir z.B. den Quelltext von z.B. DevExpress an (obwohl die an einigen Stellen mittlerweile Anfänger einsetzen).

Oder stell Jaenicke die gleiche Frage. Offensichtlich bevorzugt er auch lesbaren Code.

[TRomano]

@Dejan Vu: das artet schon wieder in einen akademischen Streit aus ...

Auch ich habe 'Clean Code' gelesen, aber sich auf 10 Zeilen zu beschränken ist auch nicht immer förderlich. Wenn es zum Beispiel um Speed & Optimization (Stichwort unrolled loops) geht, dann geht das nicht mit 10 Zeilen, sondern halt auch mal mit 30-50 Zeilen. Ansonsten sollte man natürlich versuchen die Procs/Funcs kurz zu halten, damit man den Überblick behält. Aber es ist halt auch kein Dogma und man man ist kein schlechter Codierer, wenn man 30 Zeilen Code in einer Prozedur hat !

[Dejan Vu]

Richtig. Deswegen fallen einem ja auch die Finger nicht ab, wenn man eine Methode 'auseinander faltet', also aus Performancegründen alle Vorsätze über den Haufen wirft oder sich partout nicht an die Empfehlungen des Clean Code hält. Das ist ja kein Dogma.

Es soll auch erfolgreiche Delphi-Entwickler geben, die seit Jahrzehnten in altbewährten Mustern (so gar nicht 'clean') programmieren und ihre Familie und die ihrer Angestellten gut ernähren können. Dem Akademiker und Clean-Code-Fetischisten will das zwar nicht in den Kram passen, aber so isses nun mal.

Mir ging es nur darum, aufzuzeigen, das man eigentlich überhaupt keine Präfixe oder Suffixe benötigt und diese (außer eben bei Konventionen) ein Anzeichen sein könnten, seinen Code-Stil zu verbessern oder zu verändern. Aber wer mit Präfixen glücklich ist, soll das mal so beibehalten. Hauptsache, man findet sich im Code zurecht.

Bei uns wird jedenfalls mit SOLID und Clean Code programmiert.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1310212)

Aber wer mit Präfixen glücklich ist, soll das mal so beibehalten. Hauptsache, man findet sich im Code zurecht.

Für mich ist die "richtige" Variable Benennung ein Schritt zum besser lesbaren Code... Egal wie Du das Kind jetzt nennen willst...

[EDIT]Geiler blogpost zu diesem Thema[/EDIT]

Und das Ziel sollte doch nicht nur sein, dass man(n) "sich" im Code zurecht findet, sondern auch alle anderen...

Kleines Beispiel - ab von der Norm:

Delphi-Quellcode:

if bla > 2 then  // normaler if
  begin
  end;

if bla < 0       // if mit else Teil   
  then begin

// Ganz viel Code (mehr als 7 Zeilen)






       end
  else begin // Ich wusste das es Dich gib als ich das if gelesen habe....
         
       end;

[DeddyH]

Ich fänd

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ
else
  BehandleNullOderPositiv;

lesbarer, aber was weiß denn ich?

[mquadrat]

Zitat:

Zitat von Mavarik (Beitrag 1310213)

Delphi-Quellcode:

if bla > 2 then  // normaler if
  begin
  end;

if bla < 0       // if mit else Teil   
  then begin
// Ganz viel Code (mehr als 7 Zeilen)
       end
  else begin // Ich wusste das es Dich gib als ich das if gelesen habe....
         
       end;

Ist das tatsächlich so gemeint, dass man an der Position des then erkennen können soll, ob da noch ein else folgt oder nicht? Wenn ja, dann halte ich das für eine ganz schlechte Idee. Da drückt einer mal Auto-Format und schon ist das weg.

[Mavarik]

Zitat:

Zitat von DeddyH (Beitrag 1310223)

Ich fänd

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ
else
  BehandleNullOderPositiv;

lesbarer, aber was weiß denn ich?

Klar und dann muss ich an 2 Stellen nachsehen was der Code eigentlich macht...

Abgesehen davon ist es in real live dann eher

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ(bla,Text,nochwas,true,index,undnochmehr)
else
  BehandleNullOderPositiv(bla,Text,nochwas,true,index,undnochmehr);

Macht alles nur unleserlich... Man verliert total den Zusammenhang...

Zitat:

Zitat von mquadrat (Beitrag 1310224)

Ist das tatsächlich so gemeint, dass man an der Position des then erkennen können soll, ob da noch ein else folgt oder nicht? Wenn ja, dann halte ich das für eine ganz schlechte Idee. Da drückt einer mal Auto-Format und schon ist das weg.

Super Idee, oder?

Gibt es einen der so formatiert wie die Auto-Format Routine?
Klar, wenn die richtig funktionieren würde vielleicht...

[BUG]

Zitat:

Zitat von Mavarik (Beitrag 1310232)

Abgesehen davon ist es in real live dann eher

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ(bla,Text,nochwas,true,index,undnochmehr)
else
  BehandleNullOderPositiv(bla,Text,nochwas,true,index,undnochmehr);

Sagen wir es so ... Clean Code ist ein Gesamtkonzept. Man kann nicht ein Konzept rausgreifen und erwarten das es Code jetzt sofort besser lesbar macht.

• Die Funktionen würden nicht so heißen, sondern das beschreiben, was sie machen (z.B. kämmeWookiee).
• Die vielen Parameter würde man vermeiden, z.B. durch Membervariablen.
• Im Ernst, so viele Parameter?

Es ist etwas gewöhnungsbedürftig, aber viele Algorithmen lassen sich gut als Klassen (evtl. Records in Delphi) ausdrücken.

Die absolute puren Lehre von Clean Code ist vielleicht nicht für alle Programmieraufgaben geeignet, aber für Anwendungslogik (was ist zu tun) ist es (imho) die richtige Richtung.

[Der schöne Günther]

Warum können wir uns in letzter Zeit so viel über Quellcode-Ästhetik streiten (nicht dass es schlecht wäre)? Wir sollten uns mal ein paar einfache Probe-Aufgaben ausdenken und dann schauen wer es am schönsten löst.

Der Sieger muss aber auch was gewinnen.

[Rollo62]

Will mal noch etwas in den Raum stellen.

Zitat:

Die Funktionen würden nicht so heißen, sondern das beschreiben, was sie machen (z.B. kämmeWookiee).

Ich benutze so eine Art umgekeht polnische Notation für meine Methodennamen,
also nicht kämmeWolle oder setzeDing.

Sondern so etwas:

Code:

Wolle_Schneiden()
Wolle_Kaemmen()
Wolle_Farbe_Get()

Das hört sich zwar womöglich unlogisch an, hilft aber die Methoden und Variablen sauber zu sortieren, so das oft schon im Namen eine Art "Klasse" entsteht.

Bin ich u.U. der Einzige der sowas macht ?

Und ich setze sehr lesbare, lange Namen ein die möglichst gut die Funktion beschreiben.
Mir graust es von den Verkürzlern, die so etwas in der Art produzieren:

Code:

vf:=dx+k*24modr;
Sx(vf, -k, -r);
vt:=vf+k; k:=23; dx:=k*17+vx;

Meinetwegen können die dafür einen Preis pro eingesparten Buchstaben bekommen, aber ich möchte mir sowetwas in einem halben Jahr nicht mehr durchsehen müssen.


Ich richte meinen Code an den ":=" aus, und schreibe mehrzeilige if conditions, alles damit aud einem Blick alles erfasst werden kann.
Seitdem es HD Monitore gibt muss man eigentlich keinen Bildschirmplatz mehr sparen.

Rollo

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1310232)

Gibt es einen der so formatiert wie die Auto-Format Routine?
Klar, wenn die richtig funktionieren würde vielleicht...

Ja, mich z.B., und ich habe damit auch wenige Probleme. Das ist in aktuellen Versionen eigentlich nur noch die Einrückung hier:

Delphi-Quellcode:

type
  TExample = class
  private
  var
    FTest: string;
  end;

Da fehlt mir die Einrückung ab var. Ich kann aber auch immer schreiben private var usw., dann gibt es das Problem nicht. Einmal private hielte ich aber für schöner.

Aber seit anonyme Methoden usw. korrekt formatiert werden nutze ich die automatische Formatierung sehr oft zumal ich meistens ohnehin schon genauso formatiere und nur wenig oder gar nichts noch geändert wird.

Zitat:

Zitat von Rollo62 (Beitrag 1310245)

Sondern so etwas:

Code:

Wolle_Schneiden()
Wolle_Kaemmen()
Wolle_Farbe_Get()

Das hört sich zwar womöglich unlogisch an, hilft aber die Methoden und Variablen sauber zu sortieren, so das oft schon im Namen eine Art "Klasse" entsteht.

Dann mache ich daraus auch eine Klasse...

[TRomano]

Sicherlich gibt es Entwickler, die erfolgreich sind & ihre Familien ernähren können, aber dennoch in den prozeduralen Ursprüngen des Pascals hängen geblieben sind.
Und unter anderem auch deshalb sieht man auch heute noch Projekte, wo Prozeduren/Funktionen gern mal 500 Zeilen haben. Antwort des Entwicklers/Teamleiters: "Läuft doch !".
Aber es kostet GELD ! Ist schwer wartbar, andere Entwickler brauchen mehr Zeit, um sich da einzuarbeiten usw. Vielleicht könnten diese "erfolgreichen" Entwickler noch erfolgreicher sein ?
Mir ging es darum, dass jeder seiner persönlichen Vorlieben in der Notation hat. Nach ca. 20 Projekt-Jahren ist es aber auch so, dass es in den Projekten die verschiedensten Vorgaben gibt. Dann ist es natürlich schwer sich ständig umstellen zu müssen.

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1310232)

Zitat:

Zitat von DeddyH (Beitrag 1310223)

Ich fänd

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ
else
  BehandleNullOderPositiv;

lesbarer, aber was weiß denn ich?

Klar und dann muss ich an 2 Stellen nachsehen was der Code eigentlich macht...

Falsch. Du musst nirgendwo nachschauen, was 'der Code eigentlich macht', denn durch die ordentliche Benennung der beiden Methoden (das hier sind keine guten Beispiele, um ehrlich zu sein) muss dich der Kleinkram doch gar nicht interessieren. Da würde dann stehen 'Wenn Guthaben < 0 (ist), dann berechne den Negativzins, ansonsten berechne den Positivzins'. Wie genau der Zins berechnet wird, muss dich beim überfliegen nicht interessieren, im Gegenteil: Um den Code zu erfassen, muss ich im CC-Ansatz weder Augen noch Maus noch Scrollrad bewegen. Bei Dir muss ich mir fitzelige Details anschauen und zum 'else'-Teil scrollen, um dann wieder zu verstehen, was der Code denn genau macht. Das dauert doch viel länger.

Zitat:

Abgesehen davon ist es in real live dann eher

Delphi-Quellcode:

if bla < 0 then
  BehandleNegativ(bla,Text,nochwas,true,index,undnochmehr)
else
  BehandleNullOderPositiv(bla,Text,nochwas,true,index,undnochmehr);

Macht alles nur unleserlich... Man verliert total den Zusammenhang...

Und daran erkennt man, das Du die Idee hinter 'sauberer Programmierung' nicht verstanden hast. Wer 'sauber' programmiert, hat diese ellenlangen Parameterlisten erst gar nicht. Eine Methode hat 1, maximal 3 Argumente, denn die Methode macht ja eh nur eine Sache. Und wenn ich doch mehrere Veränderliche habe, dann gehören die eigentlich immer zu einer Entität (X,Y => TPoint, Name,Vorname => TPerson etc.)

Zitat:

Zitat:

Zitat von mquadrat (Beitrag 1310224)

Gibt es einen der so formatiert wie die Auto-Format Routine?

Klar, wenn die richtig funktionieren würde vielleicht...

Nein, die würde nicht 'richtig' funktionieren, sondern einen Mavarik-Spezialmodus haben.

Bitte, lass uns es einfach so formulieren: Du bist einer der Programmierer, die seit Jahrzehnten seine Kunden mit funktionierender Software und gutem Service beglückt (das unterstelle ich Dir einfach mal), obwohl Du die Grundsätze moderner Softwareentwicklung ablehnst oder nicht befolgst und dein eigenes Ding durchziehst.

Ich wage zu behaupten, das Du in einem Team (außerhalb deines eigenen) nie auf Mitstreiter treffen wirst, die deinem Ansatz folgen wollen. Ich persönlich kann mir auch nicht vorstellen, das Du große Softwareprojekte stemmen können wirst, und ich meine wirklich große mit zig Millionen von Zeilen.

Aber solange Du keine gigantischen Projekte durchziehen musst und erfolgreich bist, muss Dich das alles nicht jucken.

Gute Häuser werden und wurden aus Ziegeln gebaut. Seit Jahrhunderten macht man das so. Kleine Häuser wird man damit in 50 Jahren noch bauen, aber Hochhäuser zieht man mittlerweile anders hoch und den Bau einer Stadt wird man mit diesem Ansatz einfach nicht hinbekommen. Mittlerweile kann man Häuser auch aus Fertigteilen aufstellen oder aus Styropor bauen, in einem Bruchteil der Zeit zu einem Bruchteil der Kosten. Aber man muss es nicht.

Zitat:

Zitat von Rollo62 (Beitrag 1310245)

Ich benutze so eine Art umgekeht polnische Notation für meine Methodennamen,
also nicht kämmeWolle oder setzeDing.

Sondern so etwas:

Code:

Wolle_Schneiden()
Wolle_Kaemmen()
Wolle_Farbe_Get()

Das hört sich zwar womöglich unlogisch an, hilft aber die Methoden und Variablen sauber zu sortieren, so das oft schon im Namen eine Art "Klasse" entsteht.

Und was hält dich davon ab, eine Wolle-Klasse zu erstellen?

Zitat:

Und ich setze sehr lesbare, lange Namen ein die möglichst gut die Funktion beschreiben.
Mir graust es von den Verkürzlern, die so etwas in der Art produzieren:

Code:

vf:=dx+k*24modr;
Sx(vf, -k, -r);
vt:=vf+k; k:=23; dx:=k*17+vx;

C-Programmierer sind dafür bekannt, zu vkzn, wsng. ("Wo es nur geht" :mrgreen)

Zitat:

Zitat von Der schöne Günther (Beitrag 1310240)

Wir sollten uns mal ein paar einfache Probe-Aufgaben ausdenken und dann schauen wer es am schönsten löst.

Sehr gute Idee.

Siehe hier: http://www.delphipraxis.net/186051-c...ml#post1310261

[Daniel]

"Falsch" ... "Du hast es nicht verstanden" ... "lehnst Grundsätze moderner Softwareentwicklung ab"
Meine Güte ...

Dass erwachsene (?) Männer (? :mrgreen: ) es tatsächlich schaffen, sich beim Thema "Wie formatiere ich meinen Quellcode" auch im Jahr 2015 noch gegenseitig ans Bein zu pinkeln, ist erstaunlich. Dass diese perfide Freude daran besteht, den anderen zu piksen ist bedauerlich, lässt aber interessante Spekulationen über den jeweiligen Menschen zu.

[Dejan Vu]

Daniel, das Du hinter jedem meiner Worte einen präpubertären Angriff vermutest, ist hinlänglich bekannt, wobei die Anspielung auf die fehlende Reife, das Geschlecht und den Charakter genau das Niveau unterbietet, das Du hier meinst, zu sehen.

Ich betone in jedem zweiten Satz, das Mavarik (und andere) durchaus gute Entwickler sind. Nur wenn man über ein Fachthema diskutiert ('Clean Code', SOLID, die sog. Prinzipien der modernen Softwareentwicklung... das sind sie nun einmal), darf man erwähnen, das der 'andere' etwas nicht verstanden hat. Es gehört nun einmal zu einem Diskurs, das man nicht alles weiß und dann darauf hingewiesen wird.

Ich verstehe vieles auch nicht und wenn ich darauf hingewiesen werde, dann freue ich mich, etwas dazulernen zu können. Nichts ist überflüssiger, als aneinander vorbeizureden, weil man sich nicht versteht.

Lass uns einfach zum Thema zurückkehren, das nicht Clean-Code hieß, sondern 'wie benennt ihr eigentlich eure Variablen, Bezeichner etc.' (sinngemäß zumindest).

[Daniel]

Meine Vermutung der fehlenden Reife wird regelmäßig auf's Neue untermauert, da kann ich nichts dafür. :stupid:
Und es ist genau die perfide Diskussionshaltung, die ich Dir vorwerfe: In einem Satz spricht Du Deinem Gegenüber offen die Kompetenz ab, um dann im (oben erwähnten) zweiten Satz, nonchalant von einem "durchaus guten Entwickler" zu sprechen. Und das soll ich Dir jetzt zu Deinen Gunsten auslegen? :mrgreen:
Es ist Deine Art zu diskutieren, deretwegen Du auch schon einmal aus dem Forum geflogen bist. Aber es ist schön, dass der Wunsch, zum Thema zurück zu finden, nun auch von Dir geäußert wird.

[mm1256]

Hallo,

nachdem ich alle Beiträge durchgelesen und dabei auch einige Anregungen gefunden habe, hier mal mein Senf zu diesem Thema. Weil es unterschiedliche Ansichten gab, was der TE grundsätzlich wollte, z.B. Daniel in #14, schlage ich mal rundum:

A vor Parametern ("Argument"): Ja
T vor Typbezeichnern ("TMyClass"): Ja
P vor Pointer-Typen: Ja
I vor Interface-Typen: Ja
F vor Klassen/Record-Feldern: Ja

Ein FormName beginnt immer mit dem Präfix "Frm", z.B. "FrmKunden". Ist es ein Hauptformular heißt die Unit "Main_Kunden.pas", ist es ein modaler Dialog entsprechend "Dlg_Kunden.pas". Bei DB-Anwendungen heißt die entsprechende Datenmodul-Unit "Dat_Kunden.pas". Die Interface-Procedure zum Anzeigen eines Formularess (ich erzeuge generell alle Formulare zur Laufzeit) ist zusammengesetzt aus dem Unit-Namen und einem "_Show", also "Main_Kunden_Show" bzw. "Dlg_Kunden_Show".

Namensgebung bei Komponenten mit 2-stelligem Präfix
cb ComboBox
ck CheckBox
lb Label
lv ListView
ed TEdit . . . usw.
gefolgt vom Variablen-Bezeichner
z.B. eine CheckBox ändert die FormVariable "FUserIsLocked" dann cbFUserIsLocked oder eine TDBCheckBox für das Datenfeld "NUMMER" heißt dann eben cbNUMMER.

Mein wichtigstes Argument für Präfixe - deren Vorliebe ich aufgrund der bisherigen Antworten anscheinend nur mit dem Kollegen "bernau" aus #10 teile:

Zitat:

Ich mag es, wenn ich in der Klasse sortieren kann und alle Edits beisammen habe

Es ist einfach sehr praktisch beim späteren Lesen des Quellcodes, wenn alle Formular-Events schön beieinander sind, und das erledigt dann die IDE so nebenbei automatisch wie gewünscht. Zu dem Thema hat es ja schon einige Diskussionen gegeben.

[Captnemo]

Da ich mir das CN-Pack installiert habe, werden bei Komponenten auf der Form diese gleich automatisch umbenannt.
Checkbox -> chkBlablabla
Edit -> edtBLablabla
Listbox -> lstBlablabla

Der Vorteil: in der CodeCompletition kann ich chk schon mal auf alle Checkboxen einschränken. Der Datentyp ist dabei ja auch schon irgendwie klar.

Diese Schreibweise ist bei mir dann irgendwann mal in Fleisch und Blut übergegangen.

Ansonsten
Klassen TBlabla
Pointer PBlabla
Klassenvariablen FBlaBla

Das voranstellen des Datentyps mache ich nur in lokalen Verablen iBlabla für Integer, sBlabla für String, usw.

Ansonsten verwende ich nach Möglichkeit Namen, die die Funktion oder den Inhalt dahinter möglichst klar benennen z.B. Function GetIndexOfPhonenummer(...)

Alles andere hole ich mir über die Möglichkeiten, die mir die IDE zur Verfügung stellt, wenn ich weitere Info's brauche.
Solange ich den Code für mich schreibe, komme ich damit sehr gut klar, auch nach Jahren.

[Sir Rufo]

Bei der Bezeichnung der Formulare mache ich es mir ganz einfach:

Die MainForm-Klasse heißt

Delphi-Quellcode:

TMainForm

und liegt in der Unit

Delphi-Quellcode:

Forms.MainForm

.
Eine Dialog-Form heißt

Delphi-Quellcode:

TFooDialog

in der Unit

Delphi-Quellcode:

Dialogs.FooDialog

.

Man könnte somit sagen, der Name folgt der Funktion ;)

[mm1256]

Zitat:

Zitat von Sir Rufo (Beitrag 1310502)

Die MainForm-Klasse heißt

Delphi-Quellcode:

TMainForm

und liegt in der Unit

Delphi-Quellcode:

Forms.MainForm

.
Eine Dialog-Form heißt

Delphi-Quellcode:

TFooDialog

in der Unit

Delphi-Quellcode:

Dialogs.FooDialog

.

Man könnte somit sagen, der Name folgt der Funktion ;)

Macht halt jeder so, wie er zurecht kommt. Bei größeren Projekten muss man halt dann "eventuell" mit kleinen Einschränkungen leben. Beispiel: Wenn ich meine App mit derzeit 18 Modulen nehme und dazu einen Modulstarter der vor dem Start mit FindWindow() schaut, ob das Modul bereits läuft, muss man schon über die Caption gehen, und nicht mehr über die Fensterklasse. Auch beim Versenden von Messages an die eigenen Apps/Module wird's ein bisserl schwieriger.

[Sir Rufo]

Ich würde dafür niemals die Caption der Form nehmen.

Dafür gibt es etwas OOP-konformes:

Delphi-Quellcode:

TObject.Equals( Obj: TObject );

[mm1256]

Wir reden aneinander vorbei. Das nützt dir halt leider nichts, wenn mehrere Instanzen (Module) mit derselben Klasse "TMainForm" am Laufen sind :(

BTW Was glaubst du wieviel "TForm1" von fremden Anwendungen ich auf meinem PC finde? Da sieht man dann sofort, wo Delphi-Programmierer am Werk waren :)