C# & Java - Was spricht gegen die "Ungarische Notation" ?

[lynxx]

Wer kennt es nicht, jede moderne IDE hat Autovervollständigen. Das hat mir damals als ich '97 mit Java anfing viel Tipparbeit gespart, einfach eine Instanz einer Klasse erzeugen, Instanzname.TAB und man bekommt eine Liste aller Funktionen & Variablen, oder man weiß schon grob was man braucht und tippt nach dem Punkt die ersten paar Zeichen und dann TAB und die IDE vervollständigt den Funktions/Variablennamen, gleiches für statische Variablen/Konstanten/Konstruktoren ..

Als ich Anfing größere Projekte zu schreiben gewöhnte ich mir an die Instanznamen mit einem Kürzel des Klassennamens zu beginnen.
Doch @pvc-junkie hielt mir vor ein paar Tagen vor das

Die ungarische Notation von Variablen ist veraltet und sollte laut C# Naming Convention nicht verwendet werden.

Ich sah das als Trollkommentar an, aber ich habe mir trotzdem darüber Gedanken gemacht.

Doch das Variablen mit einem Teil des Klassennamens beginnen hat viele Vorteile, z.B kann es sein das ich eine C#-Gui mit 4 ListBoxen, 10 CheckBoxen, 12 Labeln, 5 Buttons habe .. und sagen wir mal ich habe jetzt 4 Wochen nicht mehr an dem Projekt gearbeitet und hab mir nur ein TODO: im Kopf der Klasse hinterlassen, ich muss den Code für den AktionsButton "Hinzufügen" schreiben. Also GUI geöffnet, auf den Button geklickt -> Events & Doppelklick auf "Click", die IDE erstellt den Grundcode für den Buttonklick, ich weiss ich brauche den Eintrag der linken unteren ListBox,

Mit "Ungarischer Notation":
also tippe ich if (liTAB und bekomme eine Liste aller ListBoxen, wähle die entsprechende aus und tippe weiter ... Dann muss ich eine CheckBox prüfen, also tippe ich if (cbTAB und bekomme eine Liste aller Checkboxen, wähle die richtige aus und tippe weiter ... dann muss ich das Panel auf dem die AktionsButtons sind disablen damit der User nicht nochmal darauf klickt während gerade eine Aktion ausgeführt wird, also tippe ich pTAB wähle das Panel aus .disTABable(); .. dann brauche ich einen Text aus einer TextArea der in ein Label muss, lbTAB Label auswählen, .setTTAB(taTAB TextArea auswählen usw usf ..

Ohne "Ungarische Notation":
also tippe ich if (, wechsel in den GUI-Mode, ListBox anklicken und den Namensanfang merken oder Name aus den Properties "kopieren", zurück in den Quelltext, Namensanfang und TAB oder "einfügen", weitertippen, bei allen weiteren Komponenten das gleiche Spiel, wechsel zur GUI, Komponente anklicken und Namen merken oder kopieren, zurück zum Quelltext und dort Namensanfang und TAB oder "einfügen", es kann allerdings auch sein das eine Komponente auf einem hinteren Panel eines TabControls ist, dann muss man da auch noch das Panel umschalten (und nicht vergessen wieder zurückzuwechseln falls das Panel z.B erst aktiv ist wenn auf dem ersten schon Daten eingeben wurden), oder eine Komponente wird erst zur Laufzeit erzeugt/dynamisches Layout, dann muss man sich u.u durch den Komponenten-Baum hangeln oder bei den Globalen Variablen suchen ...
Es entstehen auch mehr Fehlerquellen: Mit etwas Pech klickt man die Komponenten nicht nur in der GUI an sondern verschiebt sie aus versehen .. oder im schlimmsten Fall man dragt sie aus versehen auf ein anderes Panel, das nach Murphy dann auch nicht die Komponente anzeigt weil die Koordinaten ausserhalb der Panelbounds sind .. dann muss man im Baum suchen wohin die Komponenten verschwunden ist und sie im Baum wieder an die richtige Stelle verschieben.

Mit "Ungarischer Notation" kann ich praktisch durchgehend Programm schreiben und nutze soviel Autovervollständigen das ich mir schon Gedanken über die nächste Zeile mache bevor ich die eine fertig habe.
Ohne "Ungarische Notation" würde ich ständig rausgerissen und das hin und hergeklicke würde bestimmt dreimal solang dauern ..

Auf Wikipedia sind einige der Einwände gegen die ungarische Notation:
* Sie machen es schwerer den Namen oder Typ einer Variablen, Funktion, Felds oder Klasse zu ändern.
Das hätte ich niemals vor und wenn doch ist es doch kein Problem per IDE den Variablennamen über alle Klassen gleichzeitig zu ändern.
* Die Kodierung des Typen einer Funktion in den Namen (die sogenannte ungarische Notation) ist hirnrissig. Der Compiler kennt die Typen ohnehin und kann diese überprüfen und es verwirrt nur den Programmierer.
Klar weiss der Compiler was für Typen die Klassen haben, aber der Entwickler soll sich die Namen aller Instanzen und deren Klassen merken!??!

Ausserdem sind Java & C# Typensicher, also man kann gar nicht aus versehen eine Funktion aufrufen die die Klasse gar nicht hat ..

Also was spricht ernsthaft gegen eine "Ungarische Notation" oder wie ist euere Meinung dazu ?

Edit: Also ich nehme keine "echte" Ungarische Notation, sondern nur ein Kürzel vor dem CamelCase Namen, z.B für eine TextBox: tbRconOutput

 

[SoDaTierchen]

Es ist wie bei allen Notationen: Jeder verteidigt seine, untern Strich ein Glaubenskrieg (es sei denn, du erzeugst Überlappungen, dann ist es wirklich Krieg).

Ich persönlich nutze für WinForms und WPF eine ungarische Notation, für alles andere jedoch UpperCamelCase. Dass man bei UI-Elementen die Namen tauschen möchte, ist eher unwahrscheinlich, dort bevorzuge ich Namen, die sich eben NICHT ohne weiteres Ändern lassen um zu verhindern, dass auf einmal irgendwelche Listener an einem Objekt dran hängen oder fehlen, die so nicht geplant waren. Im Backend-Code jedoch halte ich die ungarische Notation für sehr schlecht, da es dort doch häufiger mal vorkommt, dass man im Laufe einer Projektlebensdauer mal eine Liste zu einem HashSet degradiert oder ähnliche Transformationen ausführt.

 

[BeBur]

imHo:
ich mache wenig UI Entwicklung, aber css Klassen heißen ja auch z.B. "btn" bei Bootstrap.
Bin da also teilweise bei SoDa. Wobei ich jetzt nicht nach der konkreten Klasse gehen würde, sondern danach was etwas ist. Ein Button ist ziemlich eindeutig, aber ein Listen Widget würde ich einfach als Liste betiteln unabhängig davon, welche konkrete Klasse das hat. Damit ist es afaik nicht mehr die ungarische Notation wie sie heute oft gemeint ist.

In Backend will ich sowas nicht, der Typ ist sowieso jederzeit klar und den Platz nutze ich lieber für sprechendere Variablennamen.

 

[ProGamer]

Ich habe vor kurzem "clean code" gelesen und die Begründung in OOP gegen die ungarische Notation ist die bereits definierte Typisierung, aber auch die konkrete Namensgebung, die intuitiv sein soll. Du hast auch eine spezielle Konvention wo welche Variablen definiert sind, sowie keine Klassen, die größer sein sollten als eine Bildschirmgröße. Dadurch musst du nicht in die GUI, sondern guckst in den Bereich, in dem du deine ListBoxen definiert hast und findest dort den Namen. Aber eigentlich müsstest du das nicht, wenn du weißt wie dein Programm aussieht, weil du intuitiv den Namen deiner Variable direkt eingibst.

Das heißt nicht, dass du sie nicht benutzen darfst. Das heißt, dass wenn du einen button hast, der etwas "hinzufügt", dann erwartest du, dass du "buttonAdd" (schlecht, weil es wie die ungarische Notation ist) oder "addMyWhateverButton" (besser) existiert. Gleichzeitig verhinderst du für andere Entwickler eine Liste an
liButtonAdd
liButtonDelete
liButton...
liButton...

durchzugehen, die unübersichtlich ist, je länger sie ist. Ich sage nicht, dass du sowas hast. Ich sage, dass ich so etwas gesehen habe und mein Scrollfinger an dem Tag einen Krampf hatte, weil die Autovervollständigung zu viele Vorschläge hatte.

Die Aussage einen Variablennamen in OOP zu ändern ist schwer, ist Blödsinn. Jede vernünftige Umgebung besitzt eine Anpassungsmöglichkeit der Namensreferenz über das gesamte Projekt.

Also insgesamt: mach's wie du es für richtig hälst, bedenke jedoch, dass abhängig von der Größe des Projekts oder der Klasse andere Entwickler, die mit den Abkürzungen der ungarischen Notation nichts anfangen können, darunter leiden werden.

 

[tollertyp]

Ich kann durchaus verstehen, dass es für UIs durchaus sinnvoll sein kann, so eine Konvention zu verwenden, denn mitunter sind sonst die Bezeichner nicht eindeutig oder nur umständlich eindeutig hinzubekommen - wobei mir die Variante mit "Button" am Ende lieber ist als ein "btn"-Präfix.

Für "normale" Klassen und Methoden sehe ich da allerdings oft wenig Vorteile und Argumente wie die Aussprechbarkeit von Bezeichern.
Und ob eine Variable "id" vom Typ Long, String, UUID oder sonst was ist, ist doch eigentlich für Leser und Schreiber sekundär? Im Zweifel sorgt ein kurzes Hover in der IDE auch dafür, dass ich den Typ sehe.
Den Typ mit in den Bezeichner zu codieren bringt m.E. wenig Mehrwert, weil im Zweifel trotzdem der Bezeichner ausreichend "gut" sein muss, damit verständlich ist, was der Sinn ist...

 

[BeBur]

Um das mit der Auto-Vervollständigung mal noch konkret aufzugreifen:
Wenn man intuitive Namen vergibt, dann hat ein 'Cluster' von Objekten auch so eine art semantisches Prefix. Also alles was direkt damit zu tun hat, eine Bestellung hinzuzufügen heißt "AddOrder[...]". D.h. Ich kann mit AddOr[TAB] alles sehen, was in den funktionalen Bereich fällt, den ich gerade bearbeite. Ich komme so ebenso recht schnell zum "AddOrderConfirmBtn" oder zum "AddOrderCancelBtn". Und das ist imHo eine bessere Aufteilung als primär nach der Klasse zu sortieren.

 

[the_nobs]

Hallo

will da meinen Senf auch dazugeben:
Zwei Sachen sprechen gegen Ungarische Notation:

1. Modere Entwicklungsumgebungen zeigen dir den Typ sowieso an, meistens brauchst nur mit den cursor hinfahren und sieht wie die variable/object/... definiert wurde
2. Wenn du den Typ einer Variable änderst musst du auch den Namen ändern. was nicht immer gemacht wird
   und dann macht diese Notation mehr schaden als Nutzen.

Dem gegenüber steht der "vorteil" das du siehst was es für ein Typ ist.

wie oben bereits erwähnt, ist es Geschmackssache
IMHO ist die ungarische Notation nicht wirklich hilfreich und kann zu problemen führen.
Also warum überhaupt verwenden.

 

[Gojira]

Bei GUIs kann ich das auch noch nachvollziehen. Allerdings wähle ich dort auch Namen wie BeBur sie vorschlägt.

Bei allem anderen sehe ich keine Vorteile. Bei der handvoll Member variablen die eine Klasse hat, weiß man eigentlich was der jeweilige Typ ist. Z.B. CustomerCount wird vermutlich keinen String sein. Der Typ interessiert mich nur indirekt, viel wichtiger ist ja was die Variable ausdrückt. Und hier würde es mich nerven, jedes mal zuerst den Typ anzugeben. Ich will den CustomerCount verändern und nicht irgendeinen Integer.

 

[lynxx]

Mhhh, also ich nehme keine "echte" Ungarische Notation, sondern nur ein Kürzel vor dem CamelCase Namen, z.B für eine TextBox: tbRconOutput

Eins der Argumente auf Wikipedia ist ja u.a: "Sie machen es schwerer den Namen oder Typ einer Variablen, Funktion, Felds oder Klasse zu ändern."

Also verstoßen alle Namen wie "addMyWhateverButton", "AddOrderCancelBtn" oder alle anderen Kombinationen die den Klassennamen voll ausgeschrieben oder abgekürzt enthalten im Prinzip auch gegen die Naming Convention, nur das wenn das Kürzel oder der Klassenname am Ende steht, geht Autovervollständigen natürlich nicht ..

Edit:

Wenn man intuitive Namen vergibt, dann hat ein 'Cluster' von Objekten auch so eine art semantisches Prefix. Also alles was direkt damit zu tun hat, eine Bestellung hinzuzufügen heißt "AddOrder[...]". D.h. Ich kann mit AddOr[TAB] alles sehen, was in den funktionalen Bereich fällt, den ich gerade bearbeite. Ich komme so ebenso recht schnell zum "AddOrderConfirmBtn" oder zum "AddOrderCancelBtn". Und das ist imHo eine bessere Aufteilung als primär nach der Klasse zu sortieren.

Modere Entwicklungsumgebungen zeigen dir den Typ sowieso an, meistens brauchst nur mit den cursor hinfahren und sieht wie die variable/object/... definiert wurde

Ja das sehe ich auch so @BeBur, allerdings schreibe ich ja gerade erst eine Funktion die Objekte verwendet die evtl. nichtmal in dieser Klasse enthalten sind, das gilt auch für Deine Aussage @the_nobs , Visual Studio lagert ja alle graphischen Elemente in einer xxx.designer.cs aus, also kann man nicht einfach Mouseover über das Objekt machen. Ok man kann die Design-Klasse auch öffnen, aber da sie automatisch generiert wird muss man auch erstmal suchen wo das gewünschte Objekt ist .. bzw muss man trotzdem vorher in der GUI-Ansicht sowieso erstmal nachsehen wie das Objekt überhaupt heißt.

 

[BeBur]

Ich würde dazu sagen, dass dein Rcon Output rein inhaltlich gesehen Text ist, also z.B. rconOutputTextWidget heißen sollte. Für den enthaltenen Text würdest du dann Dinge schreiben wie rconOutputText = rconOutputTextWidget.getText();. Das finde ich persönlich äußerst sprechend.
Wenn man dann noch beachtet, technischeren Code eine Ebene tiefer zu verpacken hat man so ganz schnell Code, der sogar von jedem Laien gelesen und verstanden werden kann der noch nie programmiert hat.

Ein Button ist nunmal ein Button, sinnvoller kann man den imHo nicht bezeichnen.
Ich finde, wenn man alles so gut es geht so benennt was es ist (bzw. beinhaltet), dann erledigt sich jede Frage ganz gut. Wobei mit 'was es ist' eben nicht der technische, sondern der inhaltliche Aspekt gemeint ist.

 

[Enurian]

Mhhh, also ich nehme keine "echte" Ungarische Notation, sondern nur ein Kürzel vor dem CamelCase Namen, z.B für eine TextBox: tbRconOutput

Da kriege ich aber auch einen Rappel: Ich muss regelmäßig an den Code von anderen Leuten, oft in zusammengeklickten WindowsForms-Tools (-> zig UI-Elemente im Control).
Der eine nennt es "tb", der nächste "tbox" usw., da darf man dann erstmal raten was die Person sich nun ausgesucht hat. In den Fällen öffne ich dann das Control und schau im Designer in die Properties...

Ich gehe aber mit, dass es bei UI noch eine gewisse Berechtigung hat, überall sonst hingegen bitte nicht. Aus genannten Gründen: Typen werden schnell geändert, Mouseover zeigt den Typ sowieso, Beschränkung auf Funktion bei der Namensgebung.

 

[BeBur]

Der eine nennt es "tb", der nächste "tbox"

Das ist doch schon der best case, ich erinnere mich an ganz früher, ich konnte mir irgendwann auch selber nicht mehr merken, wie ich die 50 verschiedenen GUI Elemente denn abgekürzt habe und hatte letztendlich dadurch verschiedene Benennungen verwendet .

 

[Zuse1]

Bei der ungarischen Notation spalten sich die Geister.

Ich denke, wenn Du mit der ungarischer Notation besser klar kommst als ohne, dann nutze sie. Und andersherum: Es bringt ja nichts etwas zu machen, mit der Hoffnung das es Verständlicher wird, es aber am Ende gar nicht ist. Es wird immer Leute geben die es verteufeln und Leute die verteufeln es nicht zu nutzen.

Man sollte sich auch nicht strikt an etwas fesseln, sondern von Fall zu Fall entscheiden ob es nun sinnvoller ist oder nicht. Manchmal ist es sinnvoll, manchmal ist es überflüssig. Lohnt sich das? Muss ich das Projekt später nochmal bearbeiten? Muss jemand anderes das Projekt verstehen? Welche Programmiersprache und welche Entwicklungsumgebung wird genutzt? Wird das Projekt alleine oder von mehreren Programmieren programmiert und was halten die anderen Kollegen davon und wie einigen wir uns? usw.. Da spielen mehrere Faktoren ein Rolle.

Meine Erfahrung ist, das es durchaus sinnvoll sein kann, aber manchmal auch eben das Gegenteil bewirkt. Man sollte sich auf jeden Fall vorher gedanken drüber machen, aber das sollte man ja in allen Dingen.

 

[LencoX2]

Es spricht hauptsächlich die dagegen dass Bezeichnet kryptischer werden und damit die Code Leseichkeit leidet.
Ich dachte eigentlich, dass sich Clean Code als Quasi Standard etabliert hätte. Also selbst-Beschreibung und inhalts bezogen. Bspw.
JButton der den prüft und falls OK Speichert.
Nicht jbSave
Sondern
ifValidSaveFormBtn

 

[G00fY]

Also ich finde Hungarian Notations schrecklich wenn diese genutzt werden um den Field-Access oder -Typ zu symbolisieren (mPrivateField oder sStaticField). Das sollte Aufgabe der IDE sein.

Bei UI Elementen im Android Kontext (Java/Kotlin) schreiben wir in unseren Projekten den View Type idR in den Variablennamen, meist ans Ende.

Z.B.:
shoppingItemsRecyclerView
shoppingItemsRefreshButton
shoppingItemsCountTextView

Unter IntelliJ/Android Studio ists damit genauso einfach per Autovervollständigung auf diese zuzugreifen. Bei UI Elementen interessiert mich ja meist nicht der Typ in erster Linie, sondern die Funktion. Und wenn ich doch beispielsweise die Liste aller verfügbaren Buttons will, tippe ich einfach "Butt" () damit mir die IDE diese auflistet.

 

[character]

nur das wenn das Kürzel oder der Klassenname am Ende steht, geht Autovervollständigen natürlich nicht

Das geht mit jeder modernen IDE trotzdem. Es spricht also nichts dagegen, einen Cancel-Button "cancelButton" zu nennen.

 

[lynxx]

Eins der Argumente gegen die Ungarische Notation auf Wikipedia ist: "Sie machen es schwerer den Namen oder Typ einer Variablen, Funktion, Felds oder Klasse zu ändern."
Alle die ihren Button also CancelBtn oder CancelButton nennen, machen auch diesen Verstoß, da bin ich ja beruhigt. Eigentlich gibt es keine Naming Convention für GUI-Elemente, aber Visual Studio selber erzeugt selbst Namen wie checkBox1, also den Typ der Klasse am Anfang des Instanznamens, nur das ich diesen eben abkürze (in dem Fall in "cb") und dann per CamelCase die echte Funktion dahinter setze.

Das geht mit jeder modernen IDE trotzdem. Es spricht also nichts dagegen, einen Cancel-Button "cancelButton" zu nennen.

Oh wirklich?

Ich habe gerade mal ein TestProjekt angelegt mit OkButton und AbortButton.
Wenn ich dann im Quelltext Butto eingebe popt diese Liste auf:

• AbortButton
• AcceptButton
• Button
• ButtonBase
• ButtonBorderStyle
• ButtonRenderer
• ButtonState
• CancelButton
• CaptionButton
• DataGridViewButtonCell
• FlatButtonAppearance
• HelpButton
• IButtonControl
• MessageBoxButtons
• MessageBoxDefaultButton
• MouseButtons
• OkButton
• OnHelpButtonClicked
• RadioButton
• RadioButtonRenderer
• ScrollButton
• ToolBarButton
• ToolBarButtonClickEventArgs
• ToolBarButtonClickEventHandler
• ToolBarButtonStyle
• ToolStripButton
• ToolStripDropDownButton
• ToolStripOverflowButton
• ToolStripSplitButton
• UpdateDefaultButton

Wow .. schöne Zeitersparnis so ein Autovervollständigen - NOT!

Nenne ich Buttons aber btOk und btAbort und tippe bt so popt diese Liste auf:

• btAbort
• btOk

Man sollte sich auf jeden Fall vorher gedanken drüber machen, aber das sollte man ja in allen Dingen.

Da stimme ich Dir voll zu, ich habe mir ja Gedanken darüber gemacht, sonst hätte ich wohl kaum diesen Thread erstellt. Ich sehe ein das wenn es in geteilten Projekten Namensvorgaben gibt man diese auch einhalten sollte, aber den genauen Klassennamen auch in der Instanz zu verwenden hat einfach viel zu viele Nachteile.
Also ich werde definitiv bei meiner Methode bleiben !

 

[character]

Visual Studio selber erzeugt selbst Namen wie checkBox1, also den Typ der Klasse am Anfang des Instanznamens

Wie auch sonst, wenn es durchnummeriert wird? Soll es etwa "1CheckBox" generieren?

Wenn ich dann im Quelltext Butto eingebe popt diese Liste auf:

Wenn ich irgendwo im Quelltext einfach so irgendwas eintippe, taucht auch Unsinn auf. Das geht soweit, dass "bt" bspw. auch Sachen mit "Bluetooth" findet.

Je nach Einstellungen tauchen mit "Button" an der richtigen Stelle ganz oben in der Liste die relevanten Button-Variablen auf. Das geht mit "bt" genauso, aber eben auch mit "Button". Nicht mehr, nicht weniger.

Abgesehen davon würde man in der Praxis vermutlich eher nach "Abort" suchen, denn in der Regel habe ich ja einen bestimmen Button (o. Ä.) im Sinn, den ich verwenden will.

aber den genauen Klassennamen auch in der Instanz zu verwenden hat einfach viel zu viele Nachteile.

Das wird auch nicht verlangt. Wenn es ein ExtendedAwesomeTableWidget ist, kann man bspw. auch einfach "Table" als Suffix nehmen. Das ist deskriptiv genug.

"bt" ist für mich jedenfalls keine eindeutige Abkürzung. Ist ein "cb" eine CheckBox oder ein Callback? Als (längeres) Suffix ist das dann auch flüssiger lesbar.

In meinen Teams würde dir das so im Review jedenfalls um die Ohren fliegen. Letztendlich kannst du es natürlich machen wie du magst.

 

[Jesterfox]

Nenne ich Buttons aber btOk und btAbort und tippe bt so popt diese Liste auf:

• btAbort
• btOk

Das setzt aber voraus dass man weiß das man einen Button sucht und dieser auch immer konsistent mit bt abgekürzt wurde.

ich find da den umgekehrten Weg über die Funktion zu gehen besser. Wenn ich den AbortButton such tipp ich also Abort[TAB] und bekomm alles was mit Abort zu tun hat aufgelistet. Dann ist es egal obs ein Button oder eine selbst erstellte DrueckDingens-Klasse (kurz dd) ist ;-) außerdem seh ich dann auch gleich ob es z.B. noch irgend welche Labels dazu gibt.

 

[tollertyp]

@Jesterfox:
Eine gute IDE/Editor erkennt sogar wenn du AbB tippst, dass du den AbortButton meinst und es nicht zu "Kollisionen" kommt, aber zumindest der Vorschlag ist schon da.
(der Rest nicht mehr an dich)

Warum man eine Liste der Buttons in der Auto-Vervollständigung unbedingt sehen will erschließt sich mir auch nicht ganz. Die Wahrscheinlichkeit, dass ich alle UI-Elemente mit "Abort" sehen möchte, sehe ich als deutlich höher an, als dass ich alle Buttons sehen möchte... wenn man Probleme hat, den richtigen Button zu finden, sollte man vielleicht allgemein die Qualität der Bezeichner überdenken.
Kann es sein, dass die Auto-Vervollständigung vielleicht unter Button nichts sinnvolles bringt, weil die Elemente alle mit "bt" beginnen? Weil eigentlich würde ich dazu gerne das Projekt sehen, um mir ein Bild zu machen, wie schlimm es wirklich damit bestimmt ist, dass die IDE nicht die "richtigen" Elemente findet...

Was ich nicht ganz verstehe: Du fängst eine Diskussion an wo du eh eine vorgefestigte Meinung ist, bei etwas, was man auch als Geschmackssache ansehen kann.
Bringst dann merkwürdige Argumente wie mit dem "CheckBox1".
Ja, es ist Geschmackssache.

Ähnlich wie bei Code-Formatierung gibt es kein richtig oder falsch (mit der Ausnahme, dass geschweifte Klammern ans Ende einer Zeile gehören und nicht in eine neue Zeile). Das wichtigste ist, dass man es konsequent macht.

Also worum ging es dir?

• Deine Meinung zu festigen
• Ein "Ich gegen die Welt"-Gefühl entwickeln?
• Sich schlauer fühlen als die anderen?
• Zeitvertreib?
• Angst, doch einen Fehler zu machen, der das Ende der Welt bedeuten würde?