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

[Dejan Vu]

Zitat von Mavarik:

Zitat von DeddyH:

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 von mquadrat:

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 von Rollo62:

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 von Der schöne Günther:

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 (? ) 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.
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?
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 TMainForm und liegt in der Unit Forms.MainForm .
Eine Dialog-Form heißt TFooDialog in der Unit Dialogs.FooDialog .

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

[mm1256]

Zitat von Sir Rufo:

Die MainForm-Klasse heißt TMainForm und liegt in der Unit Forms.MainForm .
Eine Dialog-Form heißt TFooDialog in der Unit 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: 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