Bt=Button, Lb=Label, Ed=Edit

[Cöster]

Hi!

Die ersten beiden Buchstaben von Komponentennamen sollen doch idR angeben, um was für eine Komponente es sich handelt. Namen von Buttons z.B. beginnen doch mit Bt, bei Labels ist es Lb, bei Edits Ed. Diese Präfixe bestehen ja immer aus zwei Buchstaben. Gibt es irgendwo ne Übersicht, welche Präfixe die jeweiligen Komponenten besitzen? Ich kann mir kaum vorstellen, dass es jeder so machen soll wie er will. Da gibt's doch bestimmt ne Norm.

[mkinzler]

Ich kann mir nicht vorstellen, das es da ne Norm gibt. Grundsätzlich kann es jeder so halten wie er will. Nur wenn mehrere an einem Projekt arbeiten ist es ratsam sich auf Richtlinien dafür zu einigen.

[3_of_8]

Bei VisualBasic gabs mal eine Norm, die glaube ich auch weitgehend mit den "normalen" Bezeichnern bei Delphi übereinstimmen.

Mir war das allerdings nur mit 3 Buchstaben bekannt, in etwa so:

frm: TForm (und Abkömmlinge)
lbl: TLabel
btn: TButton
pnl: TPanel
edt: TEdit
cmb: TCombobox (oder wie das Ding heißt)
lst: TListBox (alternativ auch lsb, damit man es nicht mit einer Liste verwechselt)
mem: TMemo

[diComm]

Es gibt verschiedene "Styleguids" und die Präfixe für die Komponenten sind häufig ein Teil davon, Google weiss da mehr, vielleicht weiss sogar die Forensuche Rat. Allerdings sind diese Guids nur als Vorschlag zu verstehen. Das kann tatsächlich jeder halten wie er will. Nur wie erwähnt: Es ist ratsam, in einem Projekt immer den selben "Style" zu benutzen.

[Christian Seehase]

Moin Cöster,

es müssen auch nicht zwingend zwei Buchstaben sein.
Oft wirst Du z.b. btn für Button, oder lbl für Label usw. finden.
Was ich aber wichtig finde:
Man sollte sein eigenes System auch einhalten ausser (wie mkinzler ja schon sagte), wenn man sich an ein vorgegebenes System halten muss.

[Mackhack]

Ich nutze diese Prefixes:

Zitat:

Bvl - TBevel
Btn - TButton
Cbx - TComboBox
Chx - TCheckBox
Clb - TCheckListBox
Dlg - T[Open, Save...]Dialog
Fra - TFrame
Frm - TForm
Gbx - TGroupBox
ILst - TImageList
Img - TImage
Lbl - TLabel
Lbx - TListBox
Memo - TMemo
MItm - TMenuItem
MMen - TMainMenu
PBar - TProgressBar
PMen - TPopupMenu
Pnl - TPanel
Prb - TProgressBar
SBar - TStatusBar
Sbx - TScrollBox
Shp - TShape
Tree - TTreeView

[EDatabaseError]

Da mir das alles ZUU viel arbeit ist den name jeder kompo zu ändern, nutze ich die Delphi Prefixes also: TButton -> ButtonX usw.

:firejump: ein Hoch an die faulen :mrgreen:

Mfg
tobi

[Cöster]

Ich denke, man sollte wegen der Regelmäßigkeit auf jeden Fall immer die gleiche Buchstabenzahl nehmen. 1 Buchstabe ist zu wenig, 3 sind zu viel Schreibaufwand, deswegen würde ich es ganz gerne bei 2 belassen. Aber wie unterscheidet ihr dann z.B. ComboBox und CheckBox? Cm und Ch? oder Cb bei einem?

Zitat:

Zitat von EDatabaseError

Da mir das alles ZUU viel arbeit ist den name jeder kompo zu ändern, nutze ich die Delphi Prefixes also: TButton -> ButtonX usw.

:firejump: ein Hoch an die faulen :mrgreen:

Mfg
tobi

:shock: Du numerierst sie einfach durch? Wie behältst du denn da den Überblick???

[EDatabaseError]

Zitat:

Zitat von Cöster

Ich denke, man sollte wegen der Regelmäßigkeit auf jeden Fall immer die gleiche Buchstabenzahl nehmen. 1 Buchstabe ist zu wenig, 3 sind zu viel Schreibaufwand, deswegen würde ich es ganz gerne bei 2 belassen. Aber wie unterscheidet ihr dann z.B. ComboBox und CheckBox? Cm und Ch? oder Cb bei einem?

Zitat:

Zitat von EDatabaseError

Da mir das alles ZUU viel arbeit ist den name jeder kompo zu ändern, nutze ich die Delphi Prefixes also: TButton -> ButtonX usw.

:firejump: ein Hoch an die faulen :mrgreen:

Mfg
tobi

:shock: Du numerierst sie einfach durch? Wie behältst du denn da den Überblick???

Weiß ich nicht :mrgreen: ich hinterlege im code nen hint und schau da nach ;-) oder ich merk mir einfach die nummern . ja verrückt is aber so

mfg
tobi

[Cöster]

Zitat:

Zitat von EDatabaseError

Weiß ich nicht :mrgreen: ich hinterlege im code nen hint und schau da nach ;-) oder ich merk mir einfach die nummern . ja verrückt is aber so

mfg
tobi

:shock: Aber wenn du den Code 2 Wochen mal nicht siehst, kannst du dir doch nicht alle Namen merken?! Erst recht, wenn du mal 40 Kompos vom gleichen Typ hast. Wie meinst du das mit den Hints? Kommentare? Ist das nicht noch mehr Arbeit?

Ich hoffe, du stellst deine Projekte nicht Open-Source :mrgreen:

[EDatabaseError]

Zitat:

Zitat von Cöster

Zitat:

Zitat von EDatabaseError

Weiß ich nicht :mrgreen: ich hinterlege im code nen hint und schau da nach ;-) oder ich merk mir einfach die nummern . ja verrückt is aber so

mfg
tobi

:shock: Aber wenn du den Code 2 Wochen mal nicht siehst, kannst du dir doch nicht alle Namen merken?! Erst recht, wenn du mal 40 Kompos vom gleichen Typ hast. Wie meinst du das mit den Hints? Kommentare? Ist das nicht noch mehr Arbeit?

Ich hoffe, du stellst deine Projekte nicht Open-Source :mrgreen:

da ich nie ein form mit 40 buttons zuklatschen werde sondern dann gleich ne buttongroup verwenden werde / Alle parts in Panels auslage und dann in der struktur noch ein bissel mehr überblich habe. ich mal mal was in os :lol: mal schaun :mrgreen:

Mfg
tobi

[Michael Habbe]

Zitat:

Zitat von Cöster

:shock: Du numerierst sie einfach durch? Wie behältst du denn da den Überblick???

Spätestens dann, wenn man keinen Bock mehr auf die Namensvergabe von 45 Labels und nochmal soviel Edits hat, lässt man es einfach so, wie Delphi es vorschlägt. Man kann dann natürlich schonmal was durcheinanderbringen... :gruebel: :wall:


Hier mal der Link zum Style Guide von Borland:


http://community.borland.com/article...,10280,00.html

[Christian Seehase]

Moin Michael,

Zitat:

Zitat von Michael Habbe

Spätestens dann, wenn man keinen Bock mehr auf die Namensvergabe von 45 Labels und nochmal soviel Edits hat, lässt man es einfach so, wie Delphi es vorschlägt.

Nur genau in so einem Falle wird es wichtig vernünftige Namen zu vergeben.

Ich für meinen Teil mache es so (Beispiel):
Wenn ich ein Edit habe, hat das eine Aufgabe und es gehört mit Sicherheit ein Label / Static dazu.
Dann bekommt das Edit den Namen edWasEnthalteIch, und der zugehörige StaticText dann eben stxWasEnthalteIch.

Wenn man übrigens IDE-Experten wie Gexperts oder cnWizards (beide möchte ich nicht missen ;-)) verwendet, kann man sich bei der Vergabe von Prefixen für Komponenten das Leben vereinfachen.
Hier gibt es die Möglichkeit für alle mögliche Kompos einen Präfix einzutragen.
Sobald man eine neue Kompo auf das Formular legt, bekommt man einen Dialog, mit vorgegebenem Prefix, in den man nur noch den restlichen Namen eintragen muss.

[Phoenix]

Wichtig wird das vor allem bei verschiedenen TabsPages.

Ich gehe dann sogar her, und packe noch den Namen des Tabs in jedes Control auf dem Tab mit rein, damit ich da den Überblick behalte.

z.B. tabWrdlbrmpft und tabTest -> btnTestOk, btnTestCancel, btnWrdlbrmpftOK, btnWrdlbrmpftCancel

[mbamler]

Zitat:

Zitat von EDatabaseError

Da mir das alles ZUU viel arbeit ist den name jeder kompo zu ändern, nutze ich die Delphi Prefixes also: TButton -> ButtonX usw.

:firejump: ein Hoch an die faulen :mrgreen:

Mfg
tobi

Das ist eine sehr vernüftige Methode.
Eins ist klar - für das Programm selbst ist es vollkommen irrelevant wie die Objekte und Variablen heissen.

und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.


Gruß Matthias

[Balu der Bär]

Zitat:

Eins ist klar - für das Programm selbst ist es vollkommen irrelevant wie die Objekte und Variablen heissen.

Mag wohl stimmen, aber für den Programmierer ist es nicht irrelevant.

Bei einem Programm mit 38 Buttons frage ich mich wie du mit Button27.Click noch durchsiehst. :gruebel:

[Der_Unwissende]

Zitat:

Zitat von mbamler

und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.

Genau, man das ist mal ein Argument! Hast du (oder einer der faulen, dazu zählen auch Leuten den drei Zeichen zu viel Tipparbeit ist) schon mal mit mehr als einer Person an einem Projekt gearbeitet? Oder ein Projekt fortgeführt?
Im normalen Alltag vieler Entwickler kommt das nämlich häufig mal vor. Würde man hier nicht auf einen Firmenintern Styleguide pochen, hat der eine seine Labels durchnummeriert, der nächste eine Textdatei wo die Bedeutung steht und wieder der nächste verwendet die Hints. An sich ist es dann ganz toll, dass jeder der die Form einer anderen Person durchgeht nicht weiß welche Funktionalität jetzt eigentlich zu welchem Button oder Edit oder oder gehört.

Also ganz so sinnlos sind Styleguides nicht. Was die Leute angeht, die einfach nur schnell viel Code produzieren wollen, die haben leider keine Ahnung was Softwareentwicklung angeht. Statistisch gesehen schreibt ein Informatiker in einem Projekt mit allen anderen Arbeiten (die wichtig sind!) < 10 Zeilen Code pro Tag. Das sollte eigentlich deutlich machen wie unwichtig hier ein paar Zeichen mehr in einem Namen sind.

Gruß Der Unwissende

[moonwhaler]

Allen Faulen rate ich einen Blick auf CNPack, dort finden sich die CNPackWizards, eine Sammlung von wirklich brauchbaren Delphi IDE Erweiterungen (Tab rückt Blöcke ein - und Shift-Tab zurück), wenn der Cursor sich zwischen zwei Klammernpaaren befindet, werden diese markiert (D5+), aufräumen ungenutzter Units, Zeilennummernanzeige im Editor - vieles andere UND ein Tool, welches AUTOMATISCH die von Euch gewünschten Umbenennungen durchführt (natürlich konfigurabel).

Also ich bin sehr von diesen Tools und IDE Verbesserungen überzeugt... Testet die mal.

[Andidreas]

Zitat:

Zitat von mbamler

Das ist eine sehr vernüftige Methode.
Eins ist klar - für das Programm selbst ist es vollkommen irrelevant wie die Objekte und Variablen heissen.

und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.


Gruß Matthias

:shock:

also ich poch nu mal wirklich nicht auf nen styleguide... aber buttons, labels, edits etc. gescheite namen zu verpassen find ich trotzdem nützlich!!!

wo ich mit der programmierung angefangen habe, hab ich auch darauf gepfiffen wie meine felder ect. heißen und inzwischen verfluch ich die programme die ich damals geschrieben hab, und hoff das ich sie nie wieder anfassen muss...

vor allem wenn man im team arbeitet find ichs wichtig das sich dann auch die kollegen in dem programm zurecht finden...
und dazu gehören dann auch nu mal sprechende namen ;)

[MaBuSE]

Zitat:

Zitat von Cöster

Die ersten beiden Buchstaben von Komponentennamen sollen doch idR angeben, um was für eine Komponente es sich handelt. Namen von Buttons z.B. beginnen doch mit Bt, bei Labels ist es Lb, bei Edits Ed. Diese Präfixe bestehen ja immer aus zwei Buchstaben. Gibt es irgendwo ne Übersicht, welche Präfixe die jeweiligen Komponenten besitzen? Ich kann mir kaum vorstellen, dass es jeder so machen soll wie er will. Da gibt's doch bestimmt ne Norm.

Es gibt keine Norm in dem Sinne, aber es gibt mehrere verschiedene Empfehlungen, wie Quelltext zu formatieren ist.
Dabei gibt es durchaus unterschiedliche Meinungen, wie der formatierte Quelltext auszusehen hat.
Das wichtigste ist aber, dass man sich in einem Team auf einen Standard einigt und diesen dann auch konsequent einhält. Das kann man durch verschiedene Tools unterstützen.

Hier eine Liste von verschiedenen Coding Standards:

• Borland empfiehlt folgende Formatierungsregeln:
  http://community.borland.com/article...,10280,00.html
  Der Punkt 3 "naming conventions" schweigt sich aber über Deine Frage aus ;-)
  
• Deutsche Übersetzung der Borland Style Guides
  http://www.dsdt.info/grundlagen/styleguide/
  Unsere Freunde von dsdt.info haben sich die Mühe gemacht und dem Text ins deutsche Übersetzt.
  Damit gibt es nun keine Ausreden mehr sich nicht an die Richtlinien zu halten :mrgreen:
  
• Delphi 4 Developer's Guide Coding Standards Document
  von Econos - Stefan Hoffmeister (1998)
  basiert auf dem Coding standard von Xavier Pacheco and Steve Teixeira
  http://www.econos.de/delphi/cs.html
  Hier gibt es auch eine Liste mit Präfixen zu den einzelnen Komponenten
  
• Delphi Object Pascal Coding and Project Organization Standard
  von Michael P. Hollis and Mark S. Lauter
  http://onelauter.com/codestandards/
  Hier wird zwar auch nicht auf die Präfixe eingegangen, aber es wird unter anderem auch eine Verzeichnisstruktur vorgeschlagen.
  Solch ein Dokument mit den einzuhaltenden Regeln sollte in jedem Projekt / Team existieren.
  
• Delphi coding Standards
  Maintained by Mustafa GÖKMEN
  http://gokmen.selcuk.edu.tr/document.../delphi/cs.php
  Hier ist auch eine Liste mit Präfixen enthalten
  
• Delphi Identifier Naming Conventions
  von Zarko Gajic
  http://delphi.about.com/od/standards/l/bldnc.htm
  Dieser Artikel befasst sich nur mit der Benamung von Variablen

Diese Liste sollte dir erst mal einen Überblick ermöglichen.

Da es keine Norm gibt, sondern nur Empfehlungen such Dir eine aus, komplettiere sie um die Projekt / Team spezifischen Informationen und versuch sie dann auch einzuhalten.
Ich persönlich mag eine Mischung aus dem Text von Borland und dem von Econos ergänzt um einige kleine Änderungen von mir.

Viel Spaß beim Lesen.

[Cöster]

@ MaBuSE:

Danke für die vielen Links. Ich kannte bisher nur den von dsdt.info. An diesen Styleguide versuche ich mich auch schon zu halten. Einiges in den anderen Links fand ich ein bisschen komisch: z.B. Es soll keine Variablen mit Namen Temp geben. Da in den Präfix-Listen fast immer 3-buchstabige Präfixe aufgelistetn wurden, überleg ich mir jetzt, das auch zu ändern.

Was haltet ihr denn davon, lokalen Variablen den Präfix v zu geben und globalen G, wie in einem der Links beschrieben?

[Der_Unwissende]

Zitat:

Zitat von Cöster

Was haltet ihr denn davon, lokalen Variablen den Präfix v zu geben und globalen G, wie in einem der Links beschrieben?

Oh, das ist ganz schlecht. Fängt schon damit an, dass man globale Variablen einfach vermeiden sollte (setze hier einfach mal vorraus, dass du OO programmierst). Dann sollte man auch die Groß- und Kleinschreibung imho nicht für unterschiedliche Variablen missbrauchen. Vielmehr sollte der Variablenname (inkl. Präfix) entweder immer klein oder groß beginnen (je nach Styleguide).

[Kevin]

Wer jemals das Projekt eines anderen zur Weiterentwicklung übernommen hat, wird dankbar sein, wenn es leicht lesbar ist. Und dazu gehört dringend auch die Variablen-Bezeichnung. Aber selbst eigene Projekte, die man ein paar Monate nicht mehr angepackt hat, werden dadurch lesbarer. Aber jeder wie er mag... :zwinker:

[Mackhack]

Zitat:

Zitat von mbamler

und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.

Das ist ja wohl der duemmste Quatsch den ich je gehoert habe? Was machst denn bei einem Programm mit 500 Fenstern? Merken dass FormX.Button13 ein Cancel Button war oder wie?

Warum sollte Styleguide-Korrektes Arbeiten (und es sei dahingestellt ob du den offiziellen Borland-Styleg. oder einen eigenen nimmst) eine Unsicherheit verstecken. Du kennst doch die Leute ueberhaupt nicht die nach einem Styleguide arbeiten. Hier waere ich also vorsichtig mit solchen Behauptungen.

[mbamler]

Zitat:

Zitat von Mackhack

Zitat:

Zitat von mbamler

und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.

Das ist ja wohl der duemmste Quatsch den ich je gehoert habe? Was machst denn bei einem Programm mit 500 Fenstern? Merken dass FormX.Button13 ein Cancel Button war oder wie?

Warum sollte Styleguide-Korrektes Arbeiten (und es sei dahingestellt ob du den offiziellen Borland-Styleg. oder einen eigenen nimmst) eine Unsicherheit verstecken. Du kennst doch die Leute ueberhaupt nicht die nach einem Styleguide arbeiten. Hier waere ich also vorsichtig mit solchen Behauptungen.

Wenn du noch "dümmeres" Zeug lesen willst, dann lies dir einfach deine Beiträge durch ...
Man merk sofort, dass du von Softwareentwicklung nun wirklich KEINE Ahnung hast.

Styleguide-Fetischisten sind kleinkarrierte Erbsenzähler, die sich um Unwichtigkeiten kümmern anstatt sich mit dem wesentlichen der Entwicklung zu kümmern

[xaromz]

Hallo,

Zitat:

Zitat von Mackhack

Das ist ja wohl der duemmste Quatsch den ich je gehoert habe? Was machst denn bei einem Programm mit 500 Fenstern? Merken dass FormX.Button13 ein Cancel Button war oder wie?

Warum sollte Styleguide-Korrektes Arbeiten (und es sei dahingestellt ob du den offiziellen Borland-Styleg. oder einen eigenen nimmst) eine Unsicherheit verstecken. Du kennst doch die Leute ueberhaupt nicht die nach einem Styleguide arbeiten. Hier waere ich also vorsichtig mit solchen Behauptungen.

Zitat:

Zitat von mbamler

Wenn du noch "dümmeres" Zeug lesen willst, dann lies dir einfach deine Beiträge durch ...
Man merk sofort, dass du von Softwareentwicklung nun wirklich KEINE Ahnung hast.

Styleguide-Fetischisten sind kleinkarrierte Erbsenzähler, die sich um Unwichtigkeiten kümmern anstatt sich mit dem wesentlichen der Entwicklung zu kümmern

Lasst mal beide dieses OT sein :warn: . Solche Verurteilungen (Mackhack) kann man auch weniger drastisch formulieren, und persönliche Beleidigungen (mbamler) sind ja wohl wirklich nicht nötig.

Ich denke nicht, dass in diesem Thread das Für und Wider eines Sytyleguides diskutiert werden muss.

Gruß
xaromz

[Andidreas]

@xaromz (u. mods/admins)

sry wenns jetzt nochmal OT wird...

Zitat:

Zitat von mbamler

Wenn du noch "dümmeres" Zeug lesen willst, dann lies dir einfach deine Beiträge durch ...
Man merk sofort, dass du von Softwareentwicklung nun wirklich KEINE Ahnung hast.

Styleguide-Fetischisten sind kleinkarrierte Erbsenzähler, die sich um Unwichtigkeiten kümmern anstatt sich mit dem wesentlichen der Entwicklung zu kümmern

solche kommentare in deinem alter.... naja... da könnte man auch etwas mehr höflichkeit erwarten!!!


@cöster
ich kurz globale variablen (wenn ich sie mal brauch) mit gl ab...
variablen die ich in ner prozedur verwende also die nicht global sind tu ich nicht noch extra kennzeichnen...

[sakura]

Zitat:

Zitat von Andidreas

sry wenns jetzt nochmal OT wird...

Keine Sorge, die ganze Diskussion rund um Styleguides gehört zum Thema und ist nicht OT. Im Gegenteil, die Abkürzungen für Komponenten und Variablen, Felder, etc. sind oft Teil von Styleguides. Also nehmt die ruhig mit in die Diskussion rein.

@mbamler: Arbeitest Du eigentlich in einem Team oder allein? Zahlt Dir jemand Geld für Deinen Quellcode?

...:cat:...

[MaBuSE]

Zitat:

Zitat von mbamler

Zitat:

Zitat von Mackhack

Zitat:

Zitat von mbamler

und Leute, die penetrant auf dem Thema Styleguide rumreiten verstecken damit meistens nur ihre Unsicherheiten, was die eigentliche Entwicklung angeht.

Das ist ja wohl der duemmste Quatsch den ich je gehoert habe? Was machst denn bei einem Programm mit 500 Fenstern? Merken dass FormX.Button13 ein Cancel Button war oder wie?
Warum sollte Styleguide-Korrektes Arbeiten (und es sei dahingestellt ob du den offiziellen Borland-Styleg. oder einen eigenen nimmst) eine Unsicherheit verstecken. Du kennst doch die Leute ueberhaupt nicht die nach einem Styleguide arbeiten. Hier waere ich also vorsichtig mit solchen Behauptungen.

Wenn du noch "dümmeres" Zeug lesen willst, dann lies dir einfach deine Beiträge durch ...
Man merk sofort, dass du von Softwareentwicklung nun wirklich KEINE Ahnung hast.
Styleguide-Fetischisten sind kleinkarrierte Erbsenzähler, die sich um Unwichtigkeiten kümmern anstatt sich mit dem wesentlichen der Entwicklung zu kümmern

Ich gebe xaromz recht, diese eine Diskussion auf diesem Niveau sollten wir hier nicht führen.

Trotzdem möchte ich noch mal kurz auf den Sinn solcher Styleguides hindeuten,
da wohl mbamler noch nie in einem professionellen Umfeld programmiert hat.

In vielen Firmen wird in Teams an Projekten gearbeitet. Das bedeutet, es sind mehr als eine Person, die mit dem Quelltext arbeiten müssen. Oft ist auch die Fluktuation der Mitarbeiter in den Firmen recht hoch. Das bedeutet, dass die Programmierer von Quelltextpassagen oder ganzen Projekten teilweise nicht mehr in der Firma und somit auch nicht mehr ansprechbar sind. Jeder Programmierer hat seinen eigenen Programmierstil. Wenn an einem Projekt mehrere Programmier schreiben und jeder sein Ding durchzieht, wird der Code schnell unübersichtlich und die Wartung wird aufwendiger. Manchmal wird ein Projekt dann auch unwartbar. (z.B. deutsche, englische, indische und französiche Veriablennamen in der selben Anwendung. Wer soll das dann noch verstehen?)
Die Styleguides geben den Programmierer Richtlinien, wie der Code auszusehen hat. Dabei ist es weniger wichtig, für welches StyleGuide man sich entscheidet. Wichtig ist dass alle im Team den gleichen StyleGuide verwenden. Und zwar durchgehend.

Wir haben hier ein Team von ca. 40 Delphi Entwicklern. Wenn jeder das machen würde, was er wollte, wie kann dann das Team funktionieren. Es sind einige Grundregeln notwendig, damit sich auch die anderen Teammitglieder relativ schnell im Quelltext zurechtfinden.

Man muss es ja nicht übertreiben, aber ein paar Regeln sind manchmal sehr hilfreich.

Das Einhalten von StyleGuides wird in Klassenbibliotheken oder Frameworks noch wichtiger.
Stell Dir mal vor Borland hätte keine StyleGuide für die VCL gehabt, dann wären solch selbstverständliche Dinge wie die Namen der Properties nicht realisiert.

z.B. die Property Caption beinhaltet immer einen Text, der angezeigt wird.

Delphi-Quellcode:

frmMain.Caption := 'Hauptformular';
lblTest.Caption := 'Test';
myComponent.Caption := 'Test';

ohne den StyleGuide bei der Entwicklung der VCL wäre vielleicht so was herausgekommen:

Delphi-Quellcode:

frmMain.Title := 'Hauptformular';
lblTest.DisplayText := 'Test';
myComponent.Ueberschrift := 'Test'; // als deutscher Programmierer sind meine Property Namen  natürlich auch deutsch.

In diesem Beispiel sieht man auch schön, dass es z.B. auch wichtig ist, sich auf eine Sprache zur Bezeichnung der Variablen zu einigen.
Ich würde nicht verstehen, was ein Inder in indisch benamte Variablen speichert.

Wenn alle Teammitglieder deutsch sind, ist es durchaus Ok Variablen in deutsch zu benamen. Aber dann bitte alle. Sobald das Team international wird, sollte man sich auf Englisch einigen. Da man nie weiß, ob das Team später international wird, werden von vielen Teams gleich alle Benamungen in Englisch gehalten. Das macht die Sache auch einheitlicher, da die VCL ja auch komplett in Englisch ist.

Auch der Hobbyprogrammierer kann von den Vorteilen profitieren.
Wenn er nach längerer Zeit noch mal an einem seiner Projekte etwas ändern muss, findet er sich in der Regel in einem sauber strukturiertem Quelltext besser zurecht.

Wenn dann auch noch Kommentare verwendet werden, ist es fast perfekt.

Man sollte es aber auch nicht übertreiben.
Ich war mal in einem Team die hatten bis zu 12 Zeichen lange Präfixe vor jedem Objekt / Variable. Das finde ich übertrieben.
z.B.

Delphi-Quellcode:

  vparfiCount  // Var PARameter einer Funktion vom typ Integer namens COUNT

[MaBuSE]

Zitat:

Zitat von sakura

@mbamler: Arbeitest Du eigentlich in einem Team oder allein? Zahlt Dir jemand Geld für Deinen Quellcode?

Wie schafft Du es nur meinem (langen) Beitrag in nur einer Zeile zusammenzufassen? :stupid:

[miLeRiAm]

Ich bin auch einer der Faulen. Benenne maximal das Form um so wie Dinge die ich im Code wirklich OFT benötige. Anders siehts natürlich bei 'nem Kundenprojekt aus ;) aba sonst.. jo -> faul!

[MaBuSE]

Zitat:

Zitat von miLeRiAm

Ich bin auch einer der Faulen. Benenne maximal das Form um so wie Dinge die ich im Code wirklich OFT benötige. Anders siehts natürlich bei 'nem Kundenprojekt aus ;) aba sonst.. jo -> faul!

Privat mach ich das auch nicht immer durchgehend, aber im Job schon.
Wenn man sich mal dran gewöhnt hat, gehts teilweise schon automatisch ohne nachzudenken.
Es gibt ja auch viele Tools, die z.B. den Code "richtig" einrücken. Und Dir so schon mal eine Menge "Arbeit" abnehmen. (z.B. bei "fremden" Code)

[MaBuSE]

Zitat:

Mit dem Programmieren ist es wie mit der Kunst.
Hauptsache der Künstler versteht's.

Fiel mit grad so zum Thema ein ;-)

[mbamler]

Zitat:

Zitat von miLeRiAm

Ich bin auch einer der Faulen. Benenne maximal das Form um so wie Dinge die ich im Code wirklich OFT benötige. Anders siehts natürlich bei 'nem Kundenprojekt aus ;) aba sonst.. jo -> faul!

Ahhh - es gibt doch noch Hoffnung für die Entwicklerszene in Deutschland :)

Gruß
Matthias

[Andidreas]

Zitat:

Zitat von mbamler

Wenn du noch "dümmeres" Zeug lesen willst, dann lies dir einfach deine Beiträge durch ...
Man merk sofort, dass du von Softwareentwicklung nun wirklich KEINE Ahnung hast.

Styleguide-Fetischisten sind kleinkarrierte Erbsenzähler, die sich um Unwichtigkeiten kümmern anstatt sich mit dem wesentlichen der Entwicklung zu kümmern

also wenn leute die sich an nen styleguide halten keine ahnung von software entwicklung haben, dann frag ich mich gerade ernsthaft wie es ein bill gates mit seiner truppe geschafft hat eines der erfolgreichsten betriebs systeme der welt zu prodozuieren... zumals ja von microsoft auch nen eigenen styleguide gibt bzw. empfehlungen wie man ein programm entwerfen kann... aber die haben wahrscheinlich auch keine ahnung von softwareentwicklung...

[Cöster]

Zitat:

Zitat von MaBuSE

Da man nie weiß, ob das Team später international wird, werden von vielen Teams gleich alle Benamungen in Englisch gehalten. Das macht die Sache auch einheitlicher, da die VCL ja auch komplett in Englisch ist.

Sehr interessanter Punkt, über den sich sicherlich auch Streiten ließe. Ich fühle mich nämlich auch immer hin- und hergerissen. Einerseits pro Englisch, Grund hast du ja genannt.
Aber das kann man ja auch anders sehen: Wenn man deutsche Namen nimmt, kann man leichter unterscheiden, was von einem selber kommt und was Delphi einem zur Verfügung stellt. Außerdem kommt es dann seltener zu Namenskonflikten.

[MaBuSE]

Zitat:

Zitat von Cöster

Zitat:

Zitat von MaBuSE

Da man nie weiß, ob das Team später international wird, werden von vielen Teams gleich alle Benamungen in Englisch gehalten. Das macht die Sache auch einheitlicher, da die VCL ja auch komplett in Englisch ist.

Sehr interessanter Punkt, über den sich sicherlich auch Streiten ließe. Ich fühle mich nämlich auch immer hin- und hergerissen. Einerseits pro Englisch, Grund hast du ja genannt.
Aber das kann man ja auch anders sehen: Wenn man deutsche Namen nimmt, kann man leichter unterscheiden, was von einem selber kommt und was Delphi einem zur Verfügung stellt. Außerdem kommt es dann seltener zu Namenskonflikten.

Wie gesagt, es ist egal wie man es macht, man sollte es nur durchgängig gleich machen.
"Heute so, morgen anders" ist sch...

Es sollte eigentlich keine Namenskonflikte geben, sonst ist etwas an Eurem Objektmodel falsch.

[Sunlight7]

Zitat:

Zitat von Cöster

Wenn man deutsche Namen nimmt, kann man leichter unterscheiden, was von einem selber kommt und was Delphi einem zur Verfügung stellt. Außerdem kommt es dann seltener zu Namenskonflikten.

Ich stelle da vor jeder Unit, Makro oder Komponente ein S quasi Self = Eigenes :mrgreen: , dann gibts keinen Namenskonflikt, ich weiß das es von mir ist und ich habe keine Probleme mit den Äs, Ös und Üs der deutschen Sprache...

[Mackhack]

Zitat:

Zitat von Cöster

Zitat:

Zitat von MaBuSE

Da man nie weiß, ob das Team später international wird, werden von vielen Teams gleich alle Benamungen in Englisch gehalten. Das macht die Sache auch einheitlicher, da die VCL ja auch komplett in Englisch ist.

Sehr interessanter Punkt, über den sich sicherlich auch Streiten ließe. Ich fühle mich nämlich auch immer hin- und hergerissen. Einerseits pro Englisch, Grund hast du ja genannt.
Aber das kann man ja auch anders sehen: Wenn man deutsche Namen nimmt, kann man leichter unterscheiden, was von einem selber kommt und was Delphi einem zur Verfügung stellt. Außerdem kommt es dann seltener zu Namenskonflikten.

Ich finde English in diesem Falle nur aus einem Grund besser. Du kommst in der Regel mit nur einem Wort aus um der Variablen zu sagen was sie tut. Im deutschen geht das oft nicht oder es ist ein irrsinnig langes Wort!

[Lemmy1]

Ich würde gerne mal meine 2ct dazu geben. Vorweg genommen: Jeder hat sein Recht auf meine Meinung und ich respektiere alle, die ungarische Notation (das sind diese lower-case Präfixe vor den Namen) verwenden. Dennoch ist dies nicht der einzige Stil, den man so verwenden kann.

Meiner Meinung nach ist ungarische Notation eher veraltet. Gute Namen drücken den SINN einer Variable aus, nicht deren Typ. So habe ich oft erlebt, dass Entwickler beim Namen ausdenken faul werden, da sie ja bereits einen Typen im Namen drin haben.

Typische Namen aus ungarischer Notation wären ja z.B.: "sFile, fFile, iFileSize" etc. Durch das vorangestellt "s" lässt sich erkennen, dass es sich um einen String handelt. Also müsste "sFile" ja wohl ein Dateiname sein, wohingegegen das "f" auf "File" deutet (oder doch eher Float oder FunctionPointer?).

Bessere Namen für mich wären hier:

• "Filename" (kein Grund für String-Präfix...ein Filename kann nur ein String sein)
• "FilePointer/FileObject/FileHandle" (was auch immer genau gemeint ist)
• FileSize (kein Grund für Integer....eine Filesize kann nur Integer oder Cardinal sein...und sowas brauch ich kaum im Namen).

Gut bisher hab ich nur gesagt, warum man Präfixe nicht braucht, aber ich finde sie sogar teilweise schädlich. In einer modernen objektorientierten Sprache (wie Delphi) gibt es prinzipiell eine beliebige Anzahl an Typen. Ich will ja kaum für jeden dieser Typen einen eigenen Präfix erfinden. Sehr oft läuft man in Wiedersprüche (steht "ctl" nun für TCheckedTreeList oder für TCapitalTLetter...zugegeben konstruiert :) )..

Ein weiteres Problem ist die Zusammenarbeit zwischen Komponenten. Code muss nicht nur innerhalb einer Firma zusammenarbeiten, sondern auch mit Third-Party-Componenten oder Consumern. Und will man nun seinem Consumer einen Coding-Style auferlegen (Microsoft machte das zwar mit der Win32 API so, hat aber mit .Net ja auch dazu gelegt).

Für mich gibt es Ausnahmen, von der kein Präfix-davorstellen-Regel:

• Klassenvariablen brauchen ein "F", da sie sonst nicht unterscheidbar von deren Properties sind
• Klassennamen sollten ein "T" vorangestellt haben, weils einfach Standard ist
• Ebenso sollten Interfaces ein "I" haben

Wenn ich den Typen wirklich angeben MUSS, dann hinten angestellt. So heissen meine Controls z.B.
"NameLabel", "NameEdit", "OKButton". Das hat nebenbei den Vorteil, dass alle Name-Controls in der Intellisense zusammen erscheinen. Muss sich jemand anders den Code anschauen, so muss er außerdem keine Abkürzungen lernen, sondern versteht sofort, um welches Control es sich handelt.


Viel geschrieben...das sind irgendwie so die Ergebnisse aus langen Diskussionen in meiner Arbeit, wo ich einst selbst ein Hungarian Vertreter war...

Grüße