Benennen Sie Steuerelemente in Formularen nach derselben Konvention wie eine private Variable?

Question

Aus irgendeinem Grund sehe ich das nie.Gibt es einen Grund, warum nicht?Zum Beispiel mag ich _blah für private Variablen, und zumindest in Windows Forms sind Steuerelemente standardmäßig private Mitgliedsvariablen, aber ich kann mich nicht erinnern, sie jemals so benannt gesehen zu haben.Für den Fall, dass ich Kontrollobjekte in lokalen Variablen innerhalb einer Mitgliedsfunktion erstelle/speichere, ist es besonders nützlich, eine gewisse visuelle Unterscheidung zu haben.

Answer 1

Das mag für manche kontraintuitiv sein, aber wir verwenden die gefürchtete ungarische Notation für UI-Elemente.

Die Logik ist einfach:Für ein bestimmtes Datenobjekt können zwei oder mehr Steuerelemente damit verknüpft sein.Wenn Sie beispielsweise über ein Steuerelement verfügen, das in einem Textfeld ein Geburtsdatum angibt, verfügen Sie über Folgendes:

• das Textfeld
• eine Beschriftung, die angibt, dass das Textfeld für Geburtsdaten vorgesehen ist
• ein Kalendersteuerelement, mit dem Sie ein Datum auswählen können

Dafür hätte ich lblBirthDate für die Beschriftung, txtBirthDate für das Textfeld und calBirthDate für das Kalendersteuerelement.

Ich bin jedoch daran interessiert zu hören, wie andere das machen.:) :)

Answer 2

Ungarische Notation oder nicht, ich bin eher neugierig, ob Leute m_ oder _ oder was auch immer sie für standardmäßige private Mitgliedsvariablen verwenden, voranstellen.

Answer 3

Ich persönlich stelle privaten Objekten _ voran

Formularsteuerelementen wird immer der Typ vorangestellt nur Der Grund, warum ich das tue, ist Intellisense.Bei großen Formularen ist es einfacher, durch einfaches Eintippen einen Beschriftungswert zu erhalten lbl und Auswählen aus der Liste ^_^ Es folgt auch das Logik von Jon Limjap.

Obwohl dies die .NET-Codierungsrichtlinien von Microsoft betrifft, lesen Sie sie sich durch Hier.

Answer 4

Für mich hat der große Vorteil der Namenskonvention, privaten Mitgliedern einen Unterstrich voranzustellen, mit Intellisense zu tun.Da vor jedem Buchstaben im Alphabet ein Unterstrich steht, werden alle meine _privateMembers ganz oben angezeigt, wenn ich die Strg-Leertaste drücke, um Intellisense aufzurufen.

Was die Benennung betrifft, sind die Steuerelemente jedoch eine andere Geschichte.Ich denke, dass dieser Bereich angenommen wird, und aus dem gleichen Grund ist es sinnvoller, ein paar Buchstaben voranzustellen, um den Typ anzugeben (z. B. txtMyGroovyTextbox).Steuerelemente werden in Intellisense nach Typ gruppiert.

Aber bei der Arbeit ist es durchgehend VB und wir machen mPrivateMember.Ich denke, das m könnte für Modul stehen.

Answer 5

Ich bin über VB gekommen und habe das Kontrolltyp-Präfix für Kontrollen beibehalten.Meine privaten Mitglieder verwenden Kleinbuchstaben (firstLetterLowercase), während öffentliche Mitglieder Pascal/Großbuchstaben (FirstLetterUppercase) verwenden.

Wenn es zu viele Bezeichner/Mitglieder/Lokale gibt, um sich mit einer 90-prozentigen Chance daran zu erinnern/zu erraten, wie es heißt, ist wahrscheinlich mehr Abstraktion erforderlich.

Ich war nie davon überzeugt, dass ein Speichertyp-Präfix nützlich und/oder notwendig ist.Ich mache es mir jedoch zur festen Gewohnheit, dem Stil des Codes zu folgen, den ich verwende.

Answer 6

Ich nicht, aber ich schätze Ihre Logik.Ich schätze, der Grund dafür, dass die meisten Leute das nicht tun, ist, dass Unterstriche zur Entwurfszeit im Eigenschaftenfenster irgendwie hässlich aussehen würden.Es würde auch zusätzlichen horizontalen Raum beanspruchen, der in einem solchen angedockten Fenster sehr wichtig ist.

Answer 7

Ungarische Notation oder nicht, ich bin neugieriger, wenn die Leute M_ oder _ oder was auch immer sie für Standard -Variablen für private Mitglieder verwenden.

Lukas,

Ich verwende das Präfix _ für meine Klassenbibliotheksobjekte.Aus dem von mir genannten Grund verwende ich ausschließlich die ungarische Notation für die Benutzeroberfläche.

Answer 8

Ich verwende in meinen Variablennamen niemals Unterstriche.Ich habe festgestellt, dass alles andere als alphanumerische (manchmal alphanumerische) Zeichen übertrieben sind, es sei denn, die Sprache verlangt es.

Answer 9

Ich bin in der Groß-/Kleinschreibung („Titel“ ist privat, „Titel“ ist öffentlich), gemischt mit der „ungarischen“ Notation für UI-Komponenten (tbTextbox, lblLabel usw.), und ich bin froh, dass wir das nicht haben Visual Case-Insensitive-Basic-Entwickler im Team :-)

Ich mag den Unterstrich nicht, weil er irgendwie hässlich aussieht, aber ich muss zugeben, dass er einen Vorteil (oder einen Nachteil, je nachdem, was Sie meinen) hat:Im Debugger werden alle privaten Variablen oben angezeigt, da das _ am Anfang des Alphabets steht.Aber andererseits bevorzuge ich, dass mein privates/öffentliches Paar zusammen ist, weil das ein einfacheres Debuggen der Getter/Setter-Logik ermöglicht, da man die private und die öffentliche Eigenschaft nebeneinander sieht.

Answer 10

Ich schreibe den Namen der Datenbankspalte auf, die sie darstellen.

Answer 11

Ich verwende m_ für Mitgliedsvariablen, aber ich bin zunehmend versucht, einfach LowerCamelCase zu verwenden, wie ich es für Methodenparameter und lokale Variablen tue.Öffentliche Inhalte befinden sich in UpperCamelCase.

Dies scheint eine mehr oder weniger akzeptierte Konvention in der gesamten .NET-Community zu sein.