Angepinnt Grundlagen: Benennung von Controls (Update: 24.10.2010)

  • VB.NET

Es gibt 46 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Grundlagen: Benennung von Controls (Update: 24.10.2010)

    Hallo,

    Da ich in letzter Zeit oftmals Neulinge darauf hinweisen muss*, ihren Controls Namen zu geben,
    hier mal meine "Nomenklatur"

    Hinweis: Dieser Thread steht bewusst unter "Grundlagen", damit Neulinge ihn dort finden.
    Man könnte Analog dazu den Thread [VB.NET] Beispiele für guten und schlechten Code (Stil) im Hauptforum sehen.

    An dieser Stelle möchte ich nochmal darauf hinweisen, dass Fragethreads mit dem Titel "Frage" auch in "Ziegelstein" umbenannt werden könnten (meistens ist der Thread dann genauso aufschllussreich).
    Als Anleitung zur richtigen Lösungsfindung hat der User Auvid folgenden Link gepostet:
    Smart Questions
    Bitte liest ihn euch (bis zum Ende) durch und nehmt es euch zu Herzen. Das erhöht die Qualität des Forums, die Effektivität der Suchfunktion und beschleunigt die Beantwortung einer Frage, da sich dann Leue, die sich mit dem Thema gut auskennen eher in eure Topic verirren, als wenn sie "Frage" "Problem" o.ä. heißt.
    Wenn ihr eine Fehlermeldung habt, guckt am Besten ersteinmal in der MSDNnach, was diese bedeutet. In letzter not könnt ihr wenigstens noch den Namen der Fehlermeldung in die Überschrift schreiben.

    Nun aber mal los:

    1.How to
    Alle, die es wissen können diesen Schritt überspringen. Es geht um die Benennung von Controls.
    Hierzu klicken wir das Control im Designer an (Einfacher Linksklick). Nun erscheit im Eigenschaften-Dialog** (i.d.R. rechts unten) eine Liste der Eigenschaften. Sollte der Eigenschaften-Dialog nicht angezeigt sein, so drückt ihr F4 oder View->Properties Window. Sollte dies nicht der Fall sein, so vergewissert euch, dass ihr dort den "Properties"-Knopf gedrückt habt (Links von den "Events" - dem Blitz). Nun scrollt ich nach ganz oben ins Feld "(name)". Dort könnt ihr die Namen dann eingeben und sie werden automatisch in Code geändert. Sollten Fehler auftauchen, so kann es sein, dass dies nicht erfolgte und ihr die Namen im Code (-Replace-) auch noch ersetzen müsst.



    2.Dateien
    Ich benutze generell ein Kleinbuchstaben-Tripel-Prefix für Controls und Dateien

    Klassen: cls (Class)
    Module etc.: vb (Visual Basic)
    Formulare: frm (Form)
    Startformular: frmMain
    Splash-screen: frmSplash

    3.Controls

    Button: cmd (Command)
    TextBox: txt (Text)
    MaskedTextBox: mtb
    RichTextBox: rtb
    ComboBox: cmb
    ListBox: lst (List)
    ListView: lv
    TabControl: tc
    TabPage: tp
    ProgressBar: prg
    Label: lbl
    CheckBox: chk
    PictureBox: img (Image)
    RadioButton: opt (Option)
    TreeView: tv

    4. Menüs

    Hier bewaht sich die Struktur wieder, Prefix mnu:

    mnuMain -> MenuStrip
    mnuFile -> Datei
    mnuFileOpen -> Datei - Öffnen
    mnuFileSaveAs -> Datei - Speichern unter...

    5. Klassen-Dateien (danke für die Nachfrage an vb-paradise.de/user/7790-yaph1l/)

    Hier stehen meist mehrere Klassen mit Grossbuchstaben am Anfang in einem Namespace.
    Die Datei hat noch das cls-Prefix, damit Klar ist, dass es sich um eine Sammlung von Klassen handelt.
    Variablen-Deklarationen sind Geordnet:
    Public (Globale)
    Private (Lokale)
    Properties (Globale)
    Properties (Lokale)

    Darauf folgen die Methoden (Nomenklatur wie bei Globalen Variablen (auch für lokale Subs/ Functions):
    Initialisierer (MyBase.Load, New etc.)
    Functions
    Subs

    Dabei haben Lokale Variablen (-> Dim, Private) und Properties (-> Private Property) einen Kleinbuchstaben voran und Globale einen Grossbuchstaben.

    Beispiel:

    clsXmlAssistant.vb

    VB.NET-Quellcode

    1. Namespace XmlAssist
    2. Public Class XmlParser
    3. Public PBlaTestWort1Mal2 As String
    4. Dim pA As Integer
    5. Public Property VarA() As Integer
    6. Get
    7. Return pA
    8. End Get
    9. Set (value As Integer)
    10. pA = value Mod 1000000 'Wert auf Max. 6 Stellen
    11. End Set
    12. End Property
    13. 'Code
    14. End Class
    15. Public Class XmlNodeInfo
    16. 'Code
    17. End Class
    18. End Namespace


    6. Variablen

    Variblen (Werte) haben Namen, die aus einem oder mehreren Wörter bestehen.
    Dabei haben die Wörter den ersten Buchstaben groß, es sei denn, es handelt sich um das erste Wort einer Lokalen Variable:

    Lokale

    lokaleVarible
    test
    temp
    alphaBetaGamma

    Globale

    GlobaleVariable
    Test
    AnzeigeText
    AlphaBetaGammaDelta

    7. VB Einstellungen (Options)
    Options sind Compiler-Optionen, die euch vor allem auf unsauberen Code hinweisen.
    So stellt man sie sich Automatisch ein:

    1. Tools->Options

    2. Geht auf (Projects and Solutions->VB Defaults) ***
    Solltet ihr es nicht sehen, markiert "Show all Settings"
    Und vergewissert euch, dass folgende Häkchen gesetzt sind:


    8. Abschießendes
    Anregungen, Ergänzungen, Kritik, Pinnen (;)) sind gern gesehen.

    -Randnotizen-

    *Dies ist kein Ausdruck irgendeiner Pflicht a là
    Da bist da um uns zu helfen

    sondern mein Bedürftins, möglichst leserlichen Code in diesem Forum zu verbreiten.
    **Ein Screenshot ist zur Identifikation angeheftet.
    ***Könnte mir hier Jemand den Duetschen Menünamen / Einstellungsnamen nennen? Danke im Voraus

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „FAtheone“ () aus folgendem Grund: Neuer Abschnitt: VB-Einstellungen + Screenshots

    Irgendwie finde ich das mit den Dateien komisch, da du damit gegen die Regel "Klassen werden groß geschrieben" verstößt.
    Wie sähe das .NET Framework denn sonst aus:

    VB.NET-Quellcode

    1. clsConsole.WriteLine("Bla")
    2. clsWebRequest req = clsHttpWebRequest.Create(...)
    3. Dim btn As New clsButton
    4. ' usw...

    Oder heißen nur deine Dateien so?
    Ansonsten finde ich es sehr gelungen, auch wenn ich für Controls die Postfixnotaion bevorzuge.

    Viele Grüße, Phil.
    Also ich benenne nur die Dateien so, damit man sieht was es für eine Datie ist, da man Klassen ja auch gerne mal in andere Projekte kopiert und da will man ja wissen welches eine Klasse ist, der Name der Klasse ist groß geschrieben und Sinnvoll gewählt.
    Es steht ja unter Dateien ;)
    Ich benenne diese auch nur so.
    Beispiel:


    clsXmlAssistant.vb

    VB.NET-Quellcode

    1. Namespace AXml
    2. 'Klassen etc.
    3. End Namespace


    -> VB-Datei bezeichnet sich selbst als Klasse, im Code bleibt die Übersicht aka "Wo wurde das definiert"
    Ich hbae in VB-Dateien meist mehrere Klassen zu einer Funktionalität.


    Ich füge das noch hinzu.

    EDIT:
    Fertig.

    EDIT2:
    Habe ich noch i.welche Sachen / Controls vergessen?

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „FAtheone“ ()

    MAANTECH schrieb:

    Kann man fürn Button auch btn schreiben, da Command ja noch aus vb6 Zeiten stammt, oder?

    mfg MAANtech

    Nein das darfst du nicht tun !!!


    lol na klar, das sind Richtlinien keine Pflicht, du kannst deine Controls auch anders benennen. Der Sinn dahinter ist eben, willst du auf einen Button oder so zugreifen tippst du im Code "btn" oder "cmd" und schon werden in der Liste alle Buttons aufgelistet die du hast, ansonsten müsstest dir immer alle Namen der Buttons merken.
    Ich hoffe, ich darf zu diesem alten Thread noch was hinzufügen.
    Hier im Forum sollte bezüglich der Benennung von Controls eine Ausnahme gelten.
    Da war in einem Thread eine Form mit 24 Labels, die alle einen klugen und inhaltsbezogenen Namen hatten. lblAnzahlStufen, lblGeldZumEinkaufen usw.
    Ich wollte das Problem mal fix nachvollziehen und hatte eine Weile damit zu tun, die Namen dieser Labels abzugleichen.
    Wenn Probleme vorliegen und in Forms kommen viele Controls vor, sollten diese die Systemnamen haben, damit der Helfende seine Zeit zum Helfen verwenden kann und nicht zum Umbenennen verwenden muss. :thumbup:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Seit VBS 2019 wird man vom Programm hingewiesen, das Control Namen immer mit Großbuchstaben beginnen müssen..
    Vielleicht als kleine Änderung für den Post #1

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Für das Forum sind Präfixe eine nette Sache, aber wenn ihr Softwareentwickler werden wollt, gewöhnt euch diese Präfixe gar nicht erst an. Nicht umsonst gibt es bei Github und AzureDevOps Regeln, die verhindern, dass du Code einchecken kannst, wenn Präfixe erkannt werden. Seit Einführung von IntelliSense verwendet kein Entwickler den ich kenne Präfixe, denn: a überflüssig und b problematisch.

    Wenn man beispielsweise eine Form vollständig an eine Klasse bindet (sprich jedem Control eine Property zuweist) dann tut man das im Regelfall über den Namen. Um dieses Binding zu automatisieren und nicht für jede Maske ein eigenes Binding zu schreiben, wird das überwiegend über den Control-Namen und über Reflections mit dem Property-Namen gemacht. Das setzt also voraus, dass die Controls denselben Namen haben wie die Properties und sofern ihr nicht einen String in der Klasse haben wollt, der "tbVorname" heißt, sollten alle Arten von Präfixen zumindest für Controls und Properties vermieden werden. Dass das Verwenden von Präfixen von Microsoft auch gar nicht mehr unterstützt wird, sieht man unter anderem an den Standard-Bennungsregeln im Visual Studio Enterprise, wo grundsätzlich alle Variablendeklarationen gemeldet werden, die mit Kleinbuchstaben beginnen (siehe Screenshot).
    Bilder
    • Meldung VS.PNG

      2,31 kB, 586×21, 77 mal angesehen


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.
    @Yanbel Das ist schön.
    Ich habe ein TableLayoutPanel mit zwei Spalten, in der linken alles Labels mit einer entsprechenden Beschriftung, in der rechten diverse Controls (ComboBoxen, NumericUpDown, CheckBoxen).
    Die Labels und die Controls haben denselben Namen, in Übereinstimmung mit den entsprechenden Settings, der Unterschied besteht im Präfix.
    Gut, dass ich nicht bei GitHub einchecke. :D
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Yanbel schrieb:

    Seit Einführung von IntelliSense verwendet kein Entwickler den ich kenne Präfixe

    Das würde ich so nicht unterschreiben. Ich hatte dazu neulich erst einen Thread, in welchem das Thema behandelt wurde (es geht, wohlgemerkt, nur um Controls (nicht Variablen), also wie in diesem Thread hier): Benennungsregeln in .NET: Ungarische Notation bei Controls?

    Yanbel schrieb:

    Dass das Verwenden von Präfixen von Microsoft auch gar nicht mehr unterstützt wird, sieht man unter anderem an den Standard-Bennungsregeln im Visual Studio Enterprise, wo grundsätzlich alle Variablendeklarationen gemeldet werden, die mit Kleinbuchstaben beginnen

    Das ist aber doch kein Argument. Präfixe macht man dann einfach mit großen Anfangsbuchstaben. Überhaupt soll man laut MS alles groß anfangen.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum
    Irgendwelche Benennungsregeln von Controls und Variablen machen den geschriebenen Code nicht besser. Solange alle Entwickler die am Projekt arbeiten damit klar kommen ist doch alles tutti. Alle Nase lang kommt ein Cleverer daher und meint irgendwelche Regeln aufzustellen wie ich was zu benennen habe. Ich bin halt nen Rebell, und schreiben weiterhin txt_Foo und cbo_Foo...
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Seitdem alle Übergabevariablen in Sub mit s anfangen und in Function mit f habe ich einen besseren Überblick und im aktuellen Projekt diverse Fehler viel schneller gesehen/gefunden.
    Und Property in meinen Controls fangen alle mit einem p an. Damit stehen die alle in der Übersicht beisammen und ich habe auch hier einen besseren Überblick.

    Wie man es schreibt ist auch nicht so wichtig, vorallem wenn man nur alleine entwickelt. Hauptsache es findet überhaupt eine Benennung statt. Ich finde fremde Projekte immer furchtbar, wenn die
    Standartnamen vom Designer bebehalten wurden. Spätestens nach dem Namen Button5 + x verliere ich den Überblick.
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:
    @oobdoo: Das ist im Eigenentwicklungsfluss. Im Sinne von: Wenn Du allein programmierst, wirst Du Dich im Laufe der Jahre vielleicht diesbezüglich mehrfach ändern. Bis vor einigen Jahren habe ich Variablen z.B. so benannt:
    mp_X: Membervariable einer Klasse (= "class field")
    tp_X: lokale Prozedurvariable
    fp_X: Parameter einer Prozedur
    Heute? Gar keine Präfixe. Weil fast alle meiner Prozeduren ≪ 20 Zeilen sind. Da braucht es einfach keine Präfixe mehr, um die Übersicht zu behalten. Und die VisualStudioeinfärbung zur Markierung verschiedener Variablensorten macht den Rest.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    @VaporiZed
    Da hast Du natürlich recht. Die Benennung bei den Übergabevariablen hatte ich aber erst vor kurzem bei mir eingeführt.
    Das liest sich für mich allgemein viel besser als früher. Die eigene DLL zu meinem Projekt habe ich seit Jahren nicht
    mehr angefasst. Die finde ich mittlerweile nur noch schlecht lesbar. Mal schauen was die Zukunft bringt.

    Was mich wundert das scheinbar immer mehr Leute die Präfixe abschaffen wollen, aber weiterhin einer Sprache anhängen
    wo jede Zeile mit einem ; enden will. ;)

    Bei allen Vor- oder Nachteilen der Präfixe. Das weiterhin ; in vielen Sprachen verwendet wird bekomme ich nicht in meinem Kopf.
    Aktuelles Projekt: Z80 Disassembler für Schneider/Amstrad CPC :love:
    @VaporiZed Das ist genau das das ich sagen wollte. Es ist eine Frage der Zeit und natürlich auch der vorhandenen Möglichkeiten. Wenn ich heute wissen will, was sich hinter einer Variable verbirgt das lasse ich meinen Mauszeiger 2 Sekunden auf der Variable und weiß, welchen Typ sie hat, wo sie liegt und kann über F12 direkt in ihre Deklaration springen. Wenn ich eine Variable ein Präfix verpasse verrät mich das beispielsweise gar nichts über sie, aber gesehen von dem Typ. Es bringt keinen Mehrwert für den Entwickler. Auch das Argument, dass das Präfix bei Controls für irgendeiner verbesserten Übersicht aufgrund von Sortierungen hilft ist echt schwach, da es mir sehr selten etwas bringt, nach dem Controltypen zu sortieren. Höchstens mal, wenn man ein ein Control austauschen will, weil man ein eigenes Control einsetzen möchte. Das mache ich aber in 100 Prozent der Fälle direkt in der Designerklasse über Suchen und Ersetzen. Ich habe noch nie ein Anwendungsbeispiel gehabt in welchem es mir etwas gebracht hätte alle Comboboxen untereinander aufgelistet zu haben. Präfixe sind nicht mehr Zeitgemäß. Bei Großprojekten wie einem Warenwirtschaftssystem spart man sich massenhaft Code, wenn man sie einfach weglässt.

    @RodFromGermany Die Regeln muss man natürlich auch aktivieren, sonst wird das nichts. :D :D :D Aber mal Spaß beiseite, ich arbeite mit zwei Softwareentwicklern zusammen die früher für Microsoft-Tochterunternehmen und Microsoftnahe Entwicklungshäuser gearbeite haben, bevor sie zu uns gekommen sind. Und da kommen genau solche Regeln zum Einsatz.

    @Marcus Gräfe Ich kann dein Argument zum Teil nachvollziehen. Aber zu Punkt eins verstehe ich nicht ganz, Präfixe bei Klassen kann ich noch halbwegs unterschreiben, aber bei Controls. Es bringt mir überhaupt nicht zu wissen, dass sich hinter cbCustomerNo eine ComboBox verbirgt, weil ich im Regelfall gar nicht auf das Control zugreife. Tatsächlich nur einmal um das Control an ihre DataSource zu binden. Danach fasse ich das Control nie wieder an. Alles was dann noch mit den Werten passiert, passiert in meiner Binding-Klasse (Sichwort Code von UI trennen). Daher benenne ich meine die ComboBox genau wie meine Variable CustomerNo. Wofür an dieser Stelle ein Präfix? Und zu deinem zweiten Punkt: Du arbeitest in einer Microsoft IDE. Wenn die Bennungsregel kein Argument für dich ist, dann schau dir den von der ID generierten Code an. Spätestens da wirst du mir wohl zustimmen müssen, dass Microsoft selber keine Präfixe verwedetet (abgesehen von der Ausnahme Interface, wo sie tatsächlich ein sehr inkonsequentes kleines "i" verwenden). Nehmen wir nur mal den Header wenn man auf einen Button klickt. Die Übergabevariablen sender und e haben keine Präfixe, keine einzige Klasse hat ein Präfix und selbst Controls die neu auf die Maske gezogen werden bekommen Nummern und keine Präfixe. Und witzigerweise kommen trotzdem alle Entwickler gut mit dem .NET Core oder .NET Framework klar.


    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.