Angepinnt Grundlagen: Benennung von Controls (Update: 24.10.2010)

Yanbel schrieb:

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).

Ich tippe mal darauf, dass Du v.a. mit WPF arbeitest. Viele von uns arbeiten mit WinForms. Bei mir ist die Formularklasse für die Änderungen an CEs zuständig, will heißen, wenn z.B. eine CheckBox angeklickt wird, wird ein bestimmter GUI-Bereich aktiviert, um weitere Einstellungen vorzunehmen. Und dazu finde ich es schon erstmal besser, z.B. einfach zu tippen: CbAskBeforeDeleting.Enabled = CbFileIsDeletable.Checked als mir extra im Designer rauszusuchen, wie das CE heißt. V.a. wenn es dann noch ein Label gibt und vielleicht noch einen Button, die auch so heißen, also irgendwas mit FileIsDeletable, also z.B. ein Erklärungstext. Oder wenn es ein sehr großes Formular mit vielen TabPages, wo ähnliche Sachen passieren und daher sehr ähnliche Namen vergeben werden (Kundenvorgabe!). Sicherlich gibt es bessere Wege. Hab mir nur noch nicht die Mühe gemacht, nach diesen zu suchen.

Yanbel schrieb:

Daher benenne ich meine die ComboBox genau wie meine Variable CustomerNo

Das ist etwas komisch formuliert, da im selben Scope zwei Variablen nicht denselben Namen haben können. Daher: wie meinst Du das konkret?

@VaporiZed Nein, ich arbeite überwiegend mit Windows Forms, habe aber einzelne Architektur-Elemente aus WPF (wie beispielsweise das Viewmodel, etc.) in mein Framework in WinForms übernommen, da es viele Vorteile mit sich bringt. Im Prinzip kombiniere ich WPF-Architektur mit WinForms, aber das führt jetzt zu weit und ist auch keine Voraussetzung dafür UI vom Code zu trennen. Daraus resultiert natürlich, dass der Rest den du schreibst, absolut richtig ist, aber für mich in dieser Sache nicht anwendbar ist, da ich gar nicht mit den Events arbeite. Um das zu verdeutlichen und auf deine zweite Frage zu kommen:

Maske Kunde hat ein Control mit der Kundennummer, dass heißt "CostumerNo". An die Maske binde ich das ViewModel und an das Viewmodel eine List von ViewElements (einzelnen Kunden). Die Maske beinhaltet ausschließlich Code der die lauffähigkeit der Controls garantiert. (Datasources für Comboboxen füllen, Datagrids vorformatieren, ReadOnly und Enables nach Rechteverwaltung setzen, etc) Das Viewmodel übernimmt die Maskenlogik und das ViewElement ist eine 1:1 Abbildung der Maske (Hat die Maske ein Control TextBox, dann hat das ViewElement eine gleichnamige Property String). Über eine Autobinding-Klasse im Viewmodel wird jede Property an die Standardeigenschaft des Controls gebunden (Combobox.SelectedValue, TextBox.Text, CheckBox.Checked, etc). Die Daten werden dann im ViewElement geändert und bei Änderung der Property wird ein Event ausgelöst, dass die Daten aus dem ViewElement wieder in die Maske schreibt. Bis auf die einzelnen Properties ist dieses Verhalten vollständig ist den Basisklassen der Form, des Viewmodels und des ViewElements implementiert, sodass ich nur noch beim Erstellen einer neuen Maske für jedes Control eine Property im ViewElement anlegen muss. Binding, Events, Speichern, Löschen, Neu anlegen etc wird alles aus der Basisklasse vererbt und muss nur noch mit den entsprechenden Daten gefüllt werden.

Diese Architektur bietet viele Vorteile:
- Das Verhalten ist in jeder Maske identisch und bietet dementsprechen für den Anwender den maximalen Komfort
- Die Fehlersuche ist erheblich vereinfacht
- Es gibt so gut wie keinen redundaten Code
- Erweiterungen sind problemlos möglich, da Modulweise aufgebaut
- Bei komplexen Strukuren kann man das Viewelement zusätzlich an eine Business-Intelligence-Klasse binden, die erweiterte Datenverarbeitung für einen übernimmt.
- Ist eine Maske veraltet löscht man sie und bindet das ViewModel an die neue Maske (Verhalten bleibt identisch)
- Wünscht ein Kunde in allen Masken ein abgeändertes Programmverhalten passt man die Basisklasse an und das Verhalten ist in allen Masken gleichzeitig umgesetzt
- Viewmodel und Business-Intelligence und sonstige Models kann ich in eine Library auslagern und für zusätzliche Projekte verwenden (Beispiel: Kunde wünscht zusätzliche eine WebApp für den Außendienst)
etc.

Edit: Falls es wen interessiert, kann ich gerne auch mal einen vereinfachten Teil meines privaten Frameworks als Tutorial hier hochladen.

Yanbel schrieb:

Falls es wen interessiert

(Bestimmt nicht nur) mich.

Okay, dann setze ich mich mal ran, das in einem Beispiel zusammen zu fassen und ein Tutorial daraus zu basteln

um nochmal auf die Prefix-Diskussion zurückzukommen: Ich prefixiere meine Controls, und teile sie dadurch in Gruppen ein:
txt: Textbox, ck: Checkbox, lst: Listbox etc.
Wenn ich im Code auf eine Textbox zugreifen will muss ich nicht nachdenken "wie hiess die denn nochmal", sondern ich tippe "txt" und Intellisense bietet mir meine 3-5 Textboxen zur Auswahl an.
Finde ich perfekt und empfehle ich jedem weiter.

Also beispiel 4 Textboxen eines Taschenrechners: txtOperand1, txtOperator, txtOperand2, txtResult
Mir scheint, es ist völlig klar, was da bezweckt ist, und ich kann auch noch 242 Buttons, Labels, Panels und Kram auf dem Form haben - trotzdem finde ich meine Textboxen sofort wieder.
Wie würdest du die Github-konform benamen, und worin bestünde dabei die Verbesserung?

Ich benenne meine Controls danach was sie sind. Also Beispiel Kunden-Nr = "CustomerNo" oder Artikelbeschreibung= "ArticleDescription". Da brauche ich auch nicht überlegen und wie bereits beschrieben, auf Controls greife ich nie zu, da mein Viewmodel nur auf Variablen zugreift die aus der Base heraus vererbt werden. Ansonsten ist das Viewmodel völlig losgelöst von der Form und kann nötigenfalls nichtmal an eine Form sondern an ein Control gebunden werden (Bespiel: Control, das Basisdaten vom Artikel anzeigt, oder Popup-Maske für Kunden-Informationen) Die Logik steckt im Viewmodel und ist somit überall gleich. An was ich das ViewElement hinterher binde ist dem VM egal, da es autark arbeitet.

Ich habe noch nicht gesehen wie du handhabst was der @RodFromGermany schrieb.

Sehr oft habe ich ein Label was "lblBenutzername" heißt und eine Textbox die "tbBenutzername" heißt. Wie soll das gehen?
Die beiden können nicht Benutzername heißen also ist ein Präfix doch super. Ich sehe darin auch nur Vorteile.
Seit dem ich mir das angewöhnt habe ist der Zugriff wie andere auch sagen sehr viel einfacher. Denn mit "tb" bekomme ich all meine Textboxen usw.

Jo, wenn man nach dem MVVM-Pattern programmiert, kann man das so machen - dann muss man auch nicht wissen, wie die Controls heissen.
In Wpf zB brauchen Controls meist überhaupt keinen Namen.
Aber die wenigsten programmieren WinForms nach dem MVVM-Pattern.

Ich bin auch der Meinung, dass bei Controls ein Präfix nicht wirklich nachteilig ist.
Das Argument von @Yanbel Präfixe sind nicht mehr Zeitgemäß. Bei Großprojekten wie einem Warenwirtschaftssystem spart man sich massenhaft Code, wenn man sie einfach weglässt. seh ich auch nicht ganz so.
Ob nun meine Textbox "Benutzer" oder "TbBenutzer" heißt, ist meiner Ansicht nach kein massiver Unterschied was die Länge/Größe des Codes angeht. Sicherlich summieren sich die 2-3 Buchstaben je nach
Projektgröße auf, jedoch nicht bis ins Unermessliche bzw. nicht so, dass dadurch der (meiner Meinung nach) Vorteil alle Controls mit gleichem Präfix durch IntelliSense aufgelistet zu bekommen, verloren geht.

Yanbel schrieb:

weil ich im Regelfall gar nicht auf das Control zugreife

Ich allerdings schon, sogar ziemlich viel, z. B. zur Validierung von Eingaben oder für die dynamische Generierung von Anzeigetexten, z. B. auf Labels. Im Moment ist mir schleierhaft, wie man anders arbeiten soll. Wobei es natürlich auf die Art der Software ankommt. Ich bin aber noch von der "alten Schule", vielleicht liegt es daran.

@xChRoNiKx Labels werden bei mir gar nicht umbenannt, weil sie in der Regel codeseitig nicht angesprochen werden und auch für das Binding irrelevant sind.

@ErfinderDesRades Stimmt

@Schmittmuthelm 2-3 Buchstaben kommt nicht so ganz hin. Alleine in deinem Designer wird ein Label ohne dass du zusätzliche Änderungen an dem Control vorgenommen hast 11 mal mit der entsprechenden Bezeichnung eingetragen. Nur dadurch dass du es auf die Maske ziehst. Das sind bei dem Präfix "lbl" 33 Zeichen. Und mit einem Label machst du noch nicht mal was. Wie oft wird beispielsweise eine Textbox angesprochen? Rechne ma mit 30 Controls auf einer Seite (und mit 30 Controls kannst du noch keinen ganzen Kunden darstellen...) dann sind das schon 1000 Zeichen die absolut nutzlos sind und keinen Mehrwert bringen. Und die sind einfach nur da ohne dass du auch nur eine Zeile Programmcode geschrieben hast...

@Yanbel An den Aspekt hab ich im ersten Moment gar nicht gedacht, aber du hast natürlich recht. Auf der anderen Seite hatte das für mich, zumindest bis jetzt, noch keinen negativen Einfluss auf meine Projekte.
Über das Thema lässt sich sicher endlos weiter diskutieren, ich bin allerdings der Ansicht, dass ein Präfix in keiner Weise ein No-Go ist. Solang die Namensgebung nach einem sinnvollen/nachvollziehbaren Schema erfolgt und alle Beteiligten damit konform sind, sind denke ich beide/alle Wege in Ordnung.

Yanbel schrieb:

... dann sind das schon 1000 Zeichen die absolut nutzlos sind und keinen Mehrwert bringen.

Ein Argument welches absolut Sinn macht... auf einem 8-Bit System.

Yanbel schrieb:

dann sind das schon 1000 Zeichen die absolut nutzlos sind

Aus dem gleichen Grund könntest du befürworten, dass es platzsparend ist, Variablen und Objekte mit a1...z99 zu benennen.

Leute, wir sind im Jahr 2020 angelangt.
Was ist ein kB? Weniger als eine leere Datei an Verwaltungsplatz im Filesystem benötigt.

Ich kenne noch die Zeiten, als für Variablen maximal 6 Zeichen zur Verfügung standen und war heilfroh, als diese Beschränkungen weg fielen.
Sobald ich für eine brauchbare Leserlichkeit extra Kommentare benötige, habe ich gar nichts gespart.
Nur viel Zeit verplempert, das Programm zu verstehen.

@Schmittmuthelm Das ist richtig. Für sich selbst genommen ist das richtig. Aber alleine eine einheitliche Basis in einer Softwareentwicklungsfirma zu finden ist schon schwer. Der eine setzt als Präfix tb der nächste tbx wieder ein anderer verwendet gar keine Präfixe dann findet man ein uraltes Stück Code da heißen die txt. Deshalb benennt man bei uns die Variablen einfach nach dem womit sie gefüllt werden. Vorzugsweise genau so wie die Felder auf der Datenbank heißen. Das ist viel sinnvoller in meinen Augen, auch wieder im Hinblick auf das Binding. Aber klar hast du recht. Es gibt auch bei uns keine konkreten Vorgaben, jeder hat seinen eigenen Stil.

@oobdoo Jop... und jetzt rechne noch die Variablen-Präfixe dazu, die Klassenpräfixe, die Methodenheader und mach das ganze mit realistischen Zahlen und nicht mit 30 Controls, denn bei einem Kunden, Artikel, einer Rechnung, etc. reden wir hier eher von 300-500 Controls. Nehmen wir also spaßeshalber 70 Controls im Schnitt (was immer noch echt wenig ist, wenn man bedenkt, dass 40% Labels für die Beschriftungen sind), und multiplizieren das bei einer Warenwirtschaft mit ca. 200 Masken. Natürlich kommt ein Rechner damit klar und das ist auch gar nicht die Frage, sondern eher wieso baller ich mir mein Programm mit 15 Megabyte unnützen Daten zu. Wie gesagt es geht hier nicht um das 3-Masken Hobby-Projekt von Fritzchen sondern um Unternehmenssoftware die richtig was leisten muss.

@petaod Methodensignaturen und Kommentare werden nicht mit kompiliert und sind somit später nicht in der exe

Ich muss mich hier tatsächlich @ErfinderDesRades anschließen.
Nichts ist vergleichlich deliziös als ein Button der mir auch ins Gesicht schreit, dass er einer ist.
Dies hat sowohl symbolsuch-technisch als auch selbstdokumentierend große Vorteile und verbessert Eigeneffizienz meiner Meinung nach ungemein.
Dazu kommt natürlich immer wieder die Streitfrage auf ob es wirklich nötig ist den Code so "dumm" wie möglich zu schreiben.
Mann erinnere sich an das typische "Kondition mit true/false schreiben oder w/o".
Meiner Meinung nach ist leserlichkeit einfach der größte Faktor, denn für mich gilt: Je weniger Dokumentation notwendig wird, also je selbstverständlicher der Code geschrieben wird, desto Gucci.
Dann gibt es auch wieder dinge wie Klassen-member mit "m" zu präfixen, da bleibt dann aber wieder das typische "jedem das seine".

Yanbel schrieb:

Aber alleine eine einheitliche Basis in einer Softwareentwicklungsfirma zu finden ist schon schwer. Der eine setzt als Präfix tb der nächste tbx wieder ein anderer verwendet gar keine Präfixe dann findet man ein uraltes Stück Code da heißen die txt.

Genau so isses bei uns Praxis, und das ist das allergeringste Problem, was wir haben.
Jeder versteht sofort, was der Kollege meint, ob er nun btSave, cmdSave, btnSave, bt_Save oder sonstwie be-prefixt. Nur wenn das Ding einfach Save heissen würde - da gäbs Rückfragen und Änderungswünsche.
Denn Save ist wie eine Methode heissen sollte, aber kein Control.
Der einzige erforderliche Prefix-Konsenz ist, die BePrefixung inne Datei einheitlich zu halten. (Da gibts auch Partisanen, die sich nicht dran halten, aber nichtmal das(!!) ist ein Problem.)

Yanbel schrieb:

Deshalb benennt man bei uns die Variablen einfach nach dem womit sie gefüllt werden.

Das scheint mir der Punkt.
Deine Einlassung hier im Thread hat weniger mit Benamung von Controls zu tun, als mit dem MVVM-Pattern. Klar nennt man Variablen so, wie sie befüllt werden - aber ich glaub die allermeisten fassen Controls als besondere Variablen auf.
Also wenn ich Name im Code lese, erwarte ich dass das ein String ist - keinesfalls eine Textbox, Label, Combo oder sowas.
Wie gesagt: Bei MVVM ist das egal, weil man eh nicht mit Controls hantiert. (Da ists dann aber auch egal, ob man Prefixe vergibt).
Aber ich bin auch gespannt auf dein WinForms-MVVM-Demo.
Ich selbst nutze in Winforms ja auch massiv Databinding.
Aber oft genug ists eben so, dass man je nach Datenlage ein Label colorieren will, oder einen Button disablen oder auch noch viel kompliziertere Dinge.
In Wpf handel ich sowas MVVM-mässig über Bindings ab, aber in Winforms habich MVVM bislang gelassen, weil ich vermute da einen erheblichen Overhead.

ErfinderDesRades schrieb:

Jeder versteht sofort, was der Kollege meint, ob er nun btSave, cmdSave, btnSave, bt_Save oder sonstwie be-prefixt.

Da bin ich voll bei dir.
Der Name muss sprechend sein.
Das wäre er aber auch bei SaveButton.
Das ist nämlich meine übliche Nomenklatur.

Im Gegensatz zu deinem Ansatz, bei dem IntelliSense alle Buttons gruppiert, wird bei mir alles was sich um Save dreht gruppiert (Button, Methode, Label, Filedialog ...).
Mir ist diese Gruppierung wichtig.

Ich möchte nicht den Eindruck erwecken, dass meine Methode das Non-Plus-Ultra ist.
Es ist einfach das, was sich in langen Jahren als für mich praktikable erwies.
Das darf aber gerne jeder selbst handhaben, wie er möchte.

Yanbel schrieb:

Aber alleine eine einheitliche Basis in einer Softwareentwicklungsfirma zu finden ist schon schwer.

Yanbel schrieb:

Deshalb benennt man bei uns die Variablen einfach nach dem womit sie gefüllt werden.

Ist das nicht irgendwie widersprüchlich? Das ist doch auch eine einheitliche Basis, halt nur ohne Präfix oder nicht?? Sofern sich das auch auf eure Controls bezieht, wovon ich mal ausgehe.

ErfinderDesRades schrieb:

Genau so isses bei uns Praxis, und das ist das allergeringste Problem, was wir haben.

@ErfinderDesRades: Kann ich mir gut vorstellen, sah bei und nicht anders aus. Und das war hinterher auch der Grund, warum wir auf Präfixe verzichtet haben.den egal ob das Ding btnSave btSave bnSave oder sonst irgendwie heißt, gesucht wird nach "Save". Aber im Endeffekt kocht sowieso jeder Entwickler sein eigenes Süppchen.

Schmittmuthelm schrieb:

Ist das nicht irgendwie widersprüchlich? Das ist doch auch eine einheitliche Basis, halt nur ohne Präfix oder nicht??

@Schmittmuthelm: Bezog sich eher auf ein einheitliches Präfix pro Control. Denn es kommen ja auch ab und an mal neue Entwickler, die dann auch wieder eigene Präfixe mit einbringen. Daher keine Vereinheitlichung sondern einfach weglassen. Ich habe über die Jahre festgestellt, dass es das Leben sehr viel einfacher macht, wenn man sich exakt an die von Microsoft vorgesehenen Strukturen hält. Daher orientiere ich mich überwiegend am Microsoft-Code-Design. Für Desktopanwendungen nicht ganz so kritisch, aber im Azure-Umfeld auf jeden Fall eine echte Erleichterung.

petaod schrieb:

m Gegensatz zu deinem Ansatz, bei dem IntelliSense alle Buttons gruppiert, wird bei mir alles was sich um Save dreht gruppiert (Button, Methode, Label, Filedialog ...).

@petaod Und da ticken wir genau gleich. Wenn ich einen Bug im Speichern der Adressdaten beheben will, dann interessiert mich der Type des Controls gar nicht. Die Art der Gruppierung, die du hier beschreibst, ist in meinen Augen um Längen sinnvoller, denn damit hat man alle Controls zu einem Thema untereinander gruppiert.

MVVM-Demo kommt in Kürze, das Projekt ist soweit fertig. Ich habe beschlossen, dass ich der Community einen größeren Teil meines Frameworks in stark vereinfachter Form zur Verfügung stelle. Also bespielsweise auch den Umgang mit Daten und das SQL-Handing. Beim Erstellen des Projektes ist mir erst richtig krass bewusst geworden, wieviel Code da ineinander greift und was ich alles dafür schreiben muss.