Laden...

Namenskonventionen: Ungarische Notation im GUIs ok?

Erstellt von Sym vor 15 Jahren Letzter Beitrag vor 14 Jahren 17.245 Views
S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren
Namenskonventionen: Ungarische Notation im GUIs ok?

Hallo,

ich bin relativ neu im Bereich DotNet und C#.

Ich habe mich durch die Microsoft Guidelines gewühlt und finde dazu nicht die richtige Antwort.

Ich komme aus dem Java-Bereich und dort wird für das Frontend meist die ungarische Notation für Komponentenbezeichner genutzt.

Wie ist das in C#/DotNet? Mit wurde mitgeteilt, dass man dort den Komponententyp am Ende des Names mit angibt, was ich persönlich nicht schön finde.

Hat dazu wer einen offiziellen Link?

Dank und Gruß

Gelöschter Account
vor 15 Jahren

in c# nimmt man abstand von der ungarischen notation.

in der forumssuche findest du die empfohlenen Styleguides.

S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren

Ja, auch in Java nimmt man von dieser Notation Abstand. Ich habe auch hier im Forum dazu gesucht.

Bei Java wird es jedoch im FE dennoch eingesetzt, was die Control-Benamung betrifft. Ist dies bei C# auch so? Darauf wollte ich eigentlich hinaus.

S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren

Siehe dazu z.B. http://www.csharpfriends.com/articles/getarticle.aspx?articleid=336

8.2. Naming Guidelines

Generally the use of underscore characters inside names and naming according to the guidelines for Hungarian notation are considered bad practice.

Hungarian notation is a defined set of pre and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used in early Windows programming, but now is obsolete or at least should be considered deprecated. Using Hungarian notation is not allowed if you follow this guide.

And remember: a good variable name describes the semantic not the type.

An exception to this rule is GUI code. All fields and variable names that contain GUI elements like button should be postfixed with their type name without abbreviations. For example:

System.Windows.Forms.Button cancelButton;
System.Windows.Forms.TextBox nameTextBox;

Ist das gängige Praxis? Ich würde eher tbxName und btnCancel verwenden.

Gibt es dazu irgendwo einen offiziellen Link von MS?

Gelöschter Account
vor 15 Jahren

eigendlich nciht.

normalerweise schreibt man z.b.
"TimeFormatLabel"
"ThumbNailPictureBox"

viele allerdings schreiben dennoch sowas:
"lblTimeFormat"
"pbThumbNail"
was eigendlich falsch ist. dank intellisece ist das heutzutage nciht mehr notwendig soche abkürzungen zu verwenden und bei variablenbezeichnern sollte man zuerst deren verwendungszweck und anschließed optional ihren typ schreiben. "ThumbNailPictureBox -> <verwendungszweck=ThumbNail><typ=PictureBox>

Ist das gängige Praxis?

im allgemienen: ja. ich kenne es in c# garnicht anders.

S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren

Danke

3.003 Beiträge seit 2006
vor 15 Jahren

Ist das gängige Praxis? Ich würde eher tbxName und btnCancel verwenden.

Bad practice. Macht den Code schlechter lesbar, ist bei typisierten Sprachen wie C# überflüssig wie ein Kropf, und verwendet zu allem Überfluss Abkürzungen, was in sich schon wieder eine bad practice ist. Hungarian wird nicht grundlos inzwischen fast überall verworfen (die alte Frage - ich habe ein eigenes Control, nämlich eine Textbox, die sich auch wie ein Button verhalten kann - notiere ich jetzt btntbxMyControl?).

Empfehlenswerte Lektüre:
IDesign C# Coding Standard

Gruß,

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren

Für ein eigenes Control kann hat man sicher einen passenden Bezeichner.

Und über die Codecompletion ist ein Control schneller zu finden.

Meist hat man im GUI-Bereich in einer Klasse eine ganze Menge Controls. Häufig weiss man nicht genau den Namen, aber die Art des Controls.

Mittels Codecompletion lässt sich über den Controltyp schnell die gesucht Komponente finden. Wenn der Controltyp nun am Ende des Bezeichners steht, ist dies nicht so einfach, oder?

O
778 Beiträge seit 2007
vor 15 Jahren

Im Gegenteil, auch CodeCompletion freut sich über Namensgebung á la ThumbNailPictureBox, weil man dann unabhängig von nachträglichen Änderungen ist, weil dadurch die Semantik der Steuerelemente ja erhalten bleibt, aber nicht notwendigerweise der Typ ("Nein, NumericUpDownBox geht nicht, da kann man nicht zwischen 0 und NULL unterscheiden, dann halt doch eine (spezielle) TextBox").

Teilweise hab ich es auch schon gesehen, dass man sich auch bei den GUI-Elementen darauf beschränkt zu sagen, dass es überhaupt ein GUI-Element ist, aber nicht exakt welcher Typ (zB NameBox). Meines Erachtens ist das vollkommen ausreichend.

S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren

Es kommt ganz darauf an, wieviele Controls in einer Maske zu finden sind.

Habe ich in einer Maske 20 Labels, 20 Textboxen und 7 Buttons ist es doch wesentlich leichter, über Codecompletion zunächst den Bezeichner zu nennen, was die Auswahl dann einschränkt.

Ich weiß häufig nicht genau, wie das Control genau heißt, aber ich weiß, was für ein Typ es ist. Oder gibt es dann eine einfache Möglichkeit mittels intellisece die Auswahl einzuschränken?

656 Beiträge seit 2008
vor 15 Jahren

Hm, ungarische Notation, das Wort hab ich schon lange nicht mehr gehört.

Ich hab mir über die Zeit folgende Schreibweisen angewöhnt, und diese decken sich auch großteils mit unseren gängigen/festgehaltenen internen Codierungsrichlinien:

class SomeForm : Form 
{
  private int _clickCount;
  private int _btnClickMe;

  public int ClickCount { get { return _clickCount; } }
  private void ClickMe_Clicked(object sender, EventArgs e) 
  {
    int clickCount = ClickCount;
    clickCount++;
    _clickCount = clickCount;
  }
}

Mag ein wenig konfus aussehen auf den ersten Blick, aber alles hat seine daseinsberechtigung.*Member-Variablen mit Underscore, damit man sie von lokalen Variablen unterscheiden kann (_clickCount vs. clickCount) *Member-Namen nach dem Underscore in Camel-Case. *Member für Controls mit Präfix, damit ua. auch im Intellisense z.b. sämtliche Buttons unter "btn" gelistet sind (erleichtert die Suche nach einem Button, wenn man nicht selbst der Ersteller des Formulars ist). *Properties in Pascal-Case, ohne Präfix. Würde man Member nach JAck30lena's Beispiel benennen, könnte "Name" sowohl eine Property als auch ein Member sein - das ist IMO nicht allzu gut so. Auf den ersten Blick wäre auch nicht ersichtlich, ob es sich z.b um einen string handelt, oder um eine TextBox (im Gegensatz zu _txtName) wenn man onlinegurke's Beitrag noch weiter treibt und auch das "Box" weglässt. *Lokale Variablen per Camel-Case, ohne Präfix.

onlinegurke hat zwar ein gutes Argument gegen die Präfixe genannt, das müsste mMn. dann aber auch für die Suffixe gelten.
Benennt ein Entwickler das Control zum zumachen des Formulars "CloseButton", der nächste "OkButton", der dritte "SchliessenButton" und der vierte "CancelButton", kann man schon mal durch die ganze Liste scrollen um was zu finden. Die Tatsache, dass es ein Button ist, hilft mir bei der Suche nicht.
Dem würden aber zumindest die Underscores als Präfix für Member zugute kommen.

Ich werd mir bezeiten mal die anderen Links hier ansehen, aber ich bezweifle stark dass ich irgendwas an meinen Gewohnheiten ändern werde; sind immerhin (abgesehen von unseren internen Richtlinien) schon lange in dieser Form in Verwendung und helfen mir auch dabei, mich in eigenen/fremden Codes zurechtzufinden (ich suche einen Button, weil ich das Image im Code setzen will; tippe "_b" und bin dann meist schon in der Liste aller Buttons).

Am ehesten kann ich mir nur vorstellen, dass ich Konzepte finden werde, die "gar nicht so blöd" sind, und diese in meine Gewohnheiten einfließen lasse bzw. Kompromisse eingehe. Alles umwerfen und umgewöhnen, nein nein!

Gruß, BhaaL

Gelöschter Account
vor 15 Jahren

ein optimaler variablenname ist der verwendungszweck.

anstatt i in einer forschleife nimmt man lieber index. wenn man aber was zählen will, dann nimmt man count. so weiß man sofort anhand des namens, wofür die variable gut ist.

gut ist auch, das die variablennamen ausschließlich in den pdb´s zu finden sind, so kann man z.b. mit dem reflector nur dann entwicklercode lesen, wenn man auch die pdb´s hat. daher muss man nciht undingt kryptisch programmieren (codesecurity by obscurity ist also nciht notwendig 😃 ).

T
574 Beiträge seit 2008
vor 15 Jahren

eigendlich nciht.

normalerweise schreibt man z.b.
"TimeFormatLabel"
"ThumbNailPictureBox"

viele allerdings schreiben dennoch sowas:
"lblTimeFormat"
"pbThumbNail"
was eigendlich falsch ist. dank intellisece ist das heutzutage nciht mehr notwendig soche abkürzungen zu verwenden und bei variablenbezeichnern sollte man zuerst deren verwendungszweck und anschließed optional ihren typ schreiben. "ThumbNailPictureBox -> <verwendungszweck=ThumbNail><typ=PictureBox>

Ist das gängige Praxis?

im allgemienen: ja. ich kenne es in c# garnicht anders.

Zur Begründung warum wir das verwenden:
Wenn ich im PropertyFenster was suche, nämlich eine ComboBox, weil ich grad irgendwie alle ComboBoxen durchschau, muss ich nicht wissen, was die ComboBox tut oder mit was sie zusammenhängt, ich tipp mal einfach "cmb" und seh gleich alle ComboBoxen. Wenn ich das hintenran hab .. keine Chance.

Weiters:
Ich kann bei einem Namen von "ThumbNailPictureBox" nicht erkennen, ob das eine Klasse oder eine Variable ist. Klar hilft mir die Intellisense, aber wenn ich z.B Dateien vergleiche (SourceControl) hab ich keine Intellisense, daher kann ich es da nur aus dem Zusammenhang erkennen.

3.003 Beiträge seit 2006
vor 15 Jahren

Mit anderen Worten, du verwendest Namen zur syntaktischen Gruppierung von Objekten.

Aua.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

656 Beiträge seit 2008
vor 15 Jahren

Falls ich gemein war: Was spricht dagegen und tut weh? 😃

T
574 Beiträge seit 2008
vor 15 Jahren

Nein, damit war ich gemeint. Ich weiß auch nicht was dagegen spricht, solange das Studio keine Möglichkeiten in der Richtung bietet.

Gelöschter Account
vor 15 Jahren

@tkrasinger:
so komisch das jetzt klingen mag aber genau das ist der grund, warum man abstand von dieser notation nimmt.

muss ich nicht wissen, was die ComboBox tut oder mit was sie zusammenhängt,

dann bnötigst du sie ja auch nciht. wozu will man änderungen an einem control machen, wenn man nciht weiß wer es benutzt und wofür das gut ist?

angenommen, du hast 10 comboboxen. jede mit einer unterschiedlichen funktion. dann musst du, wenn du z.b. den für die namensauswahl haben willst immer "cmbName" tippen anstatt gleich "name...". zudem musst du dir alle abkürzungen merken, die vorkommen können. das mag jetzt bei .net standardcontrols noch recht leicht sein aber lass mal 100 usercontrols hinzukommen.

Ich kann bei einem Namen von "ThumbNailPictureBox" nicht erkennen, ob das eine Klasse oder eine Variable ist.

erster buchstabe groß = klasse
erster buchstabe klein = variable
membervariablen machen wir aber grundsätzlich mit m_xxx

3.003 Beiträge seit 2006
vor 15 Jahren

Bhaal, du warst nicht gemeint, sondern tkrasinger. Die Begruendung hat JAck30Lena schon geliefert. Allgemein gesprochen sollte ein Programmierer IMO nicht syntaxorientiert arbeiten, weil sich beim Entwickeln immer das Aussehen des Codes ändert (sprich: der Code sieht mit jeder Änderung anders aus, die Bedeutung bleibt aber häufig gleich).

Das heisst, der Entwickler braucht eher eine semantische Orientierung (was TUT das Ding) als eine syntaktische (wie heisst es / was ist es?).

Mich interessiert an einem Steuerelement, was es tut, nicht, was es ist. Wenn ich an der Funktionsweise etwas ändern will, muss ich die Bedeutung der Codeteile erkennen, und nicht ihre Art. Beispiel: wenn die Validierung des CAPTCHA verändert werden soll, dann muss ich nicht wissen, ob die Usereingabe in einem Textfeld, einer Combobox, per Malprogramm oder sonstwie zustande kommt - ich muss wissen, dass die Usereingabe zum CAPTCHA gehört.

Hoffe das war einigermaßen verständlich. Die Lektüre des Links, den ich oben gepostet hab', kann ich nur empfehlen. Da kann man noch einige sehr gute Ideen für "sauberes" Coden rausziehen.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
574 Beiträge seit 2008
vor 15 Jahren

Das heisst, der Entwickler braucht eher eine semantische Orientierung (was TUT das Ding) als eine syntaktische (wie heisst es / was ist es?)

Das Problem dabei ist, die semantische Bedeuting in einen Variablen-Namen zu fassen. Wenn man mit 5 Leuten an einem Projekt sitzt, bezeichnet jeder eine Eingabefeld für einen Preis einer Ware anders, daher kann man zwar wissen das man was mit einem Preis sucht, aber wie genau das ding heißt was man nicht. Daher ist es einfacher mal alle txt* anzuschauen, dann seh ich das ziemlich schnell.
(@Jack: Wenn du 100 Controls manuell auf einer Form hast, is irgendwas schiefgegangen, da kennt sich dann keiner mehr aus und wenn noch dazu z.b. 100 Textboxen auf einer Form sind, also .. naja)

Wie würdet ihr z.b. die Eingabetextbox im Forum hier beschreiben? messageTextBox? Wie die Images draüber? boldImage, italicImage,uUnderlineImage .., imageImage?
Oder das ding nach "TT": resizeEditorImage oder vielleicht editorResizerImage oder editorWindowResizerImage ..?

Gelöschter Account
vor 15 Jahren

(@Jack: Wenn du 100 Controls manuell auf einer Form hast, is irgendwas schiefgegangen, da kennt sich dann keiner mehr aus und wenn noch dazu z.b. 100 Textboxen auf einer Form sind, also .. naja)

nicht auf einer form. reicht ja wenn sie in einem projekt existieren. willst du dir alle möglichen abkürzungen merken wenn du ein ganz bestimmtes auf der form finden möchtest (die anderen müssen ja nicht auf der form sein...)?

Wenn man mit 5 Leuten an einem Projekt sitzt, bezeichnet jeder eine Eingabefeld für einen Preis einer Ware anders,

schwaches argument.....
etwa "PriceXXX"?

was machst du, wenn es aussieht wie eine textbox (im designer usw..) aber keine textbox ist? suchst du dann alle member der form durch?

Wie würdet ihr z.b. die Eingabetextbox im Forum hier beschreiben?

MessageTextBox?

T
574 Beiträge seit 2008
vor 15 Jahren

Wenn man mit 5 Leuten an einem Projekt sitzt, bezeichnet jeder eine Eingabefeld für einen Preis einer Ware anders,

schwaches argument.....
etwa "PriceXXX"?

Man kann natürlich auch stur sein ...

Na wie wärs z.B. mit ArticlePrice, ItemPrice, ProductPrice, commodityprice (dict.leo)
Nachdem wir alle keine Native-Speaker hier sind und trotzdem meist Englisch coden, kommt dann sowas raus.

was machst du, wenn es aussieht wie eine textbox (im designer usw..) aber keine textbox ist? suchst du dann alle member der form durch?

Und wenn was ein Button ist und wie ein Image aussieht erkennst du bei "doessomethingButton", dass du das suchst? Da schaust aber auch 2 mal nach obs ned a "doessomethingImage" gibt.

Gelöschter Account
vor 15 Jahren

iddqdXXXPrice ist aber auch nciht besser.

das man jetzt bei manchen bezeichnern unter umständen nicht einig wird, kann passieren aber das ist 1. eher eine außnahme und 2. ist es weit aus schwerer erstmal die korrekte abkürzung zu finden, bevor man durch die n möglichkeiten navigieren kann.

3.003 Beiträge seit 2006
vor 15 Jahren

Man kann natürlich auch stur sein ...

Na wie wärs z.B. mit ArticlePrice, ItemPrice, ProductPrice, commodityprice (dict.leo)
Nachdem wir alle keine Native-Speaker hier sind und trotzdem meist Englisch coden, kommt dann sowas raus.

Ein Blick in alte Versionen unserer Hauptanwendung zeigt folgende Notation für eine Combobox:


cbElement 
ddElement //dropdown...
cmbElement
cbxElement

Wie war also gleich dein Argument? 😉

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
574 Beiträge seit 2008
vor 15 Jahren

Ein Blick in alte Versionen unserer Hauptanwendung zeigt folgende Notation für eine Combobox:

  
cbElement   
ddElement //dropdown...  
cmbElement  
cbxElement  
  

Dafür gibts Codingrichtlinien (und Haue für jeden der sich nicht dran hält 😉 )

Wörter und Bedeutungen kann man nicht vereinheitlichen ...

Gelöschter Account
vor 15 Jahren

du musst es ja nicht in einem wort abbilden. du darfst nur keine whitespaces oder unterstriche verwenden.

in jedem fall ist ein komisch klingender ausdruck besser als eine kryptische aneinanderreihung von zeichen. es funktioniert wirklich so, wie ich es beschreibe. wie gesagt: ich kenne es garnicht anders in c# und es funktioniert.

allerdings kann ich c-code nur noch mit großer mühe lesen... um mal ein nachteil zu nennen.

3.003 Beiträge seit 2006
vor 15 Jahren

Dafür gibts Codingrichtlinien (und Haue für jeden der sich nicht dran hält 😉 )

Reingefallen. Genau diese Aussage wollte ich von dir hören.
Ich geh dann mal die 3-Buchstaben-Abkürzungen für die knapp 200 User Controls in unseren Projekten auswendig lernen. I may be some time.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
574 Beiträge seit 2008
vor 15 Jahren

Ich geh dann mal die 3-Buchstaben-Abkürzungen für die knapp 200 User Controls in unseren Projekten auswendig lernen. I may be some time

UserControls werden bei uns nur als "ctl*" bezeichnet, damit ist eindeutig, dass es sich um ein UserControl handelt. Den Rest seh ich über die IntelliSense.

Für 200 UserControls Prefixe überlegen würd auch niemand machen.

Gelöschter Account
vor 15 Jahren

@tkrasinger:
wie macht ihr das denn bei den variablen in einer klasse?

mach es doch einfach so wie die öffentlichen bezeichner im framework.

da wird auch meist ausgeschrieben und immer versucht möglichst sprechend zu formulieren.

3.003 Beiträge seit 2006
vor 15 Jahren

*grunz*
Na gut. Übersetzt in DIESE Praxis sieht dann eine Form so aus:


protected MatchCode<IBObject> ctlStatisticGraphSelector;
protected IReportCombo ctlReportView;
protected Nameeinsetzen ctlReportDetailSelector;
protected Nameeinsetzen ctlReportContextSwitch;
/* go on... */

Den Unterschied dazu, das "ctl" wegzulassen...öööhm...ist da einer?

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Gelöschter Account
vor 15 Jahren

ein kleiner unterschied ist da. wenn man ctl eingibt, dann sortiert die intellisece alle nicht-ctlXXX aus und mann kann mit den pfeiltasten oder der mouse programmieren. ob das aber so gut ist... vermutlich kann man sich an alles gewöhnen.

3.003 Beiträge seit 2006
vor 15 Jahren

Einige empfohlene Praktiken beinhalten ja das Benennen von Membervariablen mit "m_Name". In dem Fall kürzt das das Tippen von "this." ab und ist noch einzusehen.
Nun mag das prefixen von Controls ähnlich wirken. Der Unterschied ist aber, dass kein Arbeitsschritt abgekürzt wird.

Kleinigkeiten, letzten Endes. Man kommt eventuell irgendwann an einen Punkt, wo die gewohnte Notation nicht mehr zielführend ist. Das kann sein, weil viele neue Programmierer dazukommen (die das alte System nicht kennen, und mühselig lernen müssten, während sie eigentlich die Software mühselig lernen sollten), das kann die schiere Masse an Variablen sein, das kann sonstwas sein. Dann und nur dann sollte man sich Gedanken machen, der Rest ist IMO verschwendete Lebenszeit.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

S
Sym Themenstarter:in
9 Beiträge seit 2009
vor 15 Jahren

Mit anderen Worten, du verwendest Namen zur syntaktischen Gruppierung von Objekten.

Aua.

LaTino

Genau! Im Bereich FE (und zwar in den Forms) würde ich diese Notation verwenden. Gerade weil ich beim Entwickeln mich eher daran erinnere, um was für ein Control es sich handelt. Und über Intelisence möchte ich ja gerade mein gesuchtest Control finden.

Das diese Notation im restlichen C#-Bereich nicht mehr verwendet wird, sehe ich auch so. Da lässt sich der Code (meiner Meinung nach) aber auch besser Strukturieren.

[...]
normalerweise schreibt man z.b.
"TimeFormatLabel"
"ThumbNailPictureBox"[...]

Den ControlTyp hinten anzuhängen, halte ich für mindestens ebenso unsinnig. Dann kann ich ihn auch davor schreiben und habe dadurch eine einfache Einschränkung in der Codecompletion.

52 Beiträge seit 2007
vor 15 Jahren

Klar, wenn man etwa alle TextBoxen mit txb* o. ä. beginnt, kann uns IntelliSense alle txb* - Namen auflisten und zur Auswahl anbieten. Wenn man *TextBox etc. am Ende des Namens schreibt, tja dann... wie war das noch? No chance!

Doch das hat mich auf eine Idee gebracht, warum eigentlich nicht auch IntelliSense benutzen um Namen vorzublenden die mit einem bestimmten String aufhören? Könnte es sein dass man Intelli* noch Intelligenter machen könnte? Ich denke ja. Wieso nicht etwa mit wildcards arbeiten, etwa nach dem Stil *TextBox ? Oder auch etwa Text ? Wäre doch eine sinnvolle Erweiterung oder nicht?

Gruß,
yb

yb~~~~~~~~~~~~

Gelöschter Account
vor 15 Jahren

Klar, wenn man etwa alle TextBoxen mit txb* o. ä. beginnt, kann uns IntelliSense alle txb* - Namen auflisten und zur Auswahl anbieten. Wenn man *TextBox etc. am Ende des Namens schreibt, tja dann... wie war das noch? No chance!

tja, das ist eben die philosphiefrage. ich z.b. bekomme bei dieser notation kurzfristig kopfschmerzen, da ich dann anfange krampfhaft zu überlegen, was denn dieses kürzel schon wieder bedeuten mag. das habe ich ber bereits einige male bereits geschrieben.

tatsache ist, das man auch ohne kryptische präfixe ausgezeichnet arbeiten kann.

S
8.746 Beiträge seit 2005
vor 15 Jahren

Ist immer lustig wie Coding-Style-Fragen zu solch hitzigen Diskussionen führen. Kommt gleich nach: Schmeckt Apfel oder Birne besser.

Wenn ich mal die vielen Styles der letzten 20 Jahre Revue passieren lasse, fällt mir auf:

  1. Styles sind in allererster Linie _Moden _(es lassen sich auch gute Argumente für Stehkragen finden...)
  2. Abkürzungen sind MEGA-OUT.
  3. Typkennzeichnungen sind zunehmend OUT.

Grundsätzlich denke ich aber: Im Zeitalter von Refactoring-Funktionen ist das Thema Variablenbenamsung ein Fliegenschiss-Problem.

IMHO: Ich halte es (mittlerweile) mit MS: Geschwätzig und Postfix. Mich hat die Codeästhetik überzeugt. "cbxBtnCntrl" ist wie Trainingsanzug, Schlappen und Vokuhila in einem. Schmerzen produziert das bei mir zwar nicht, aber es ist einfach unschön, wenn man 8 Stunden am Tag vor dem Code sitzt und dauernd das Gefühl hat sich kratzen zu müssen.

1.665 Beiträge seit 2006
vor 15 Jahren

Wir arbeiten ganz primitiv mit folgenden Benennungsschemas:

TextBox textBoxName;
TextBox textBoxFirstname;
ListView listViewAppointments;
Button buttonOK;

//
this.textBoxFirstname.Text = ...

ohne Abkürzung, ohne nix. Lediglich UserControl stellt die Ausnahme mit "uc" als Präfix dar (=> "ucEditor"). Man sollte ja eigentlich wissen, mit welchen Typen von Controls man auf der UI arbeitet. So hat man mit dem ausgeschriebenen und leserlichen Typnamen eine logische Gruppierung. Ich bekomme da oft Magenschmerzen wenn ich txtXYZ oder btnCancel lese.

Letztendlich kann es jeder frei entscheiden. Manche meinen, den Unterstrich in Variablennamen immer noch verwenden zu müssen oder z.B. auch Ordnernamen mit Unterstrichen zu versehen, weil sie in den alten Zeiten zu sehr stecken geblieben sind (soll sich jetzt keiner beleidigt fühlen, ich finde das einfach nur humbug in der heutigen Zeit). Kann jeder für sich entscheiden, ich stehe da mehr zu Leserlichkeit.

Gelöschter Account
vor 15 Jahren

ein gutes beispiel warum ich im allgmeinen abkürzungen hasse:
TableAdapter.Fill & Thread

T
574 Beiträge seit 2008
vor 15 Jahren

ein gutes beispiel warum ich im allgmeinen abkürzungen hasse:

>

*g* - nicht mal wenn ich mich anstreng, komm ich drauf was mfg_ heißen könnte ... aber einen Prefix + Vollname-Postfix zu verwenden, das ist dann wohl etwas zuviel.

1.002 Beiträge seit 2007
vor 14 Jahren

Hallo svenson,

"cbxBtnCntrl" ist wie Trainingsanzug, Schlappen und Vokuhila in einem.

you made my day 😃!

m0rius

Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg

328 Beiträge seit 2006
vor 14 Jahren

in Visual Stusio 2010 ist IntelliSense auch deutlich schlauer geworden. gibt man zum Beispiel TextBox ein, findet er auch alle textBoxen, welche zum Beispiel "NameTextBox" heissen 👍

Träume nicht dein Leben sondern lebe deinen Traum.
Viele Grüße, David Teck

S
469 Beiträge seit 2007
vor 14 Jahren

Als ich als Student angefangen habe in meiner Firma C# zu programmieren, wollte ich mich vorbildlich streng an die Design-Richtlinien halten (damals: garkeine Typinfos bei Control-Namen), also ja nicht btnXYZ oder ButtonXYZ oder XYZButton sondern nur XYZ.
Es war eine Umgewöhnung, denn ich hatte in alten Visual Basic (duck..hab ich nur gaanz kurz gemacht) und sogar alten Java-Büchern gelernt, man sollte Controls mit Prefixen versehen btn.., txt.., cb...
Ich halte mich auch an sehr viele Richtlinien, die von vielen, auch Profis, missachtet werden, z.b. Klammere ich bei Schleifen/ifs immer, auch bei Einzeilern.
ABER nach einigen Jahren habe ich aber zu btn etc. zurückgefunden.
Warum?
Früher hab ich meinen Code angeguckt und sofort gesehen was ein Button, eine Combo ist etc. Heute muss ich mit der Maus drüberfahren und warten bis der Tooltip erscheint. Schnarch, das ist für mich verlorene Zeit.
Zusätzlich gilt das Argument, CodeCompletition ist auch einfacher, wenn man nicht weiß wie die Textbox im Detail heißt...hmm Nickname oder Displayname oder Alias?) Wenn ich grad mal kein VS zur Verfügung habe (Beispiel, ich arbeite mit SourceSafe und mache da einen Compare zweier Versionen mit dem SourceSafe Compare-Editor..ohne Prefixe seh ich da garnicht was was ist).
Außerdem mag ich es nicht so, wenn direkt in der Ereignis-Funktion, z.b. im Click, viel Code ausgeführt wird. ich lager das gern in ne extra Funktion aus, die ich dann auch von anderswo aufrufen kann. Nu hab ich nen Button StartCalculations, der Berechnungen starten soll. Intuitiv würde ich die Funktion zum Berechnen auch StartCalculations() nennen, aber geht ja nicht wenn der Button genauso heißt.
Des weiteren benenne ich meist alle Controls, auch wenn ich nicht im Code darauf zugreife. Wenn ich nun eine Textbox für den NickName habe und ein Label davor wo "NickName" draufsteht, wie nenn ich dann was? Hmm, lblNickName und txtNickName! Ohne Prefixe müsste ich mir da den Kopf zerbrechen oder was doofes erfinden (NickNameInput für die Eingabe und das Label nur NickName? 8o).
Das Prefix macht den Namen nur 2-3 Zeichen länger, ich habe aber bisher noch keinen Nachteil in Lesbarkeit oder ähnlichem gesehen, und Performance-technisch ist es eh schnuppe.
Da sich die "Empfehlungen" bei der Benamsung von Controls im Laufe der Zeit immer wieder ändern und zum Teils sogar von Sprache zu Sprache verschieden sind, sehe ich es so wie einer der Vorredner...es ist eine Mode, Mode ist Geschmacksache und man braucht nicht jede Mode mitmachen. Da gibt es wesentlich wichtigere Richtlinien die man sich einverleiben sollte, für mich ist es diese nicht wert "mandatory" zu sein, wenn dann "recommended".
Arbeitet man allerdings im Team, sollten die Teammitglieder sich auf einen gemeinsamen Nenner einigen.

[EDIT: Formatierung]

gruß
sth_Weird

++++++++++++++++++++~+
Fluchen ist die einzige Sprache, die jeder Programmierer perfekt beherrscht


Linux is for free...if your time is worth nothing
++++++++++++++++++++~+

T
574 Beiträge seit 2008
vor 14 Jahren

genau meine Meinung, v.a. der Teil midm SourceSafe wo's halt nun mal keine Intellisense gibt ...