Bt=Button, Lb=Label, Ed=Edit

[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 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 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 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 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 von Cöster:

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 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 , 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 von Cöster:

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