Angepinnt Beispiele für guten und schlechten Code (Stil)

Mir war kurz langweilig, daher habe ich mal diesen Thread von Anfang an gelesen.
Es mag schon alles stimmen wie Ihr es hier schreibt und vieles ist auch wirklich notwendig.
Vieles ist aber wirklich Kinderei und hier sind wirklich viele i-Tüpferl-Reiter mäßig unterwegs.

Es ist bei vielem so unnötig darüber überhaupt zu diskutieren. Beispielsweise ob = "" oder <> "xx" geschrieben wird oder If variable=true then oder if variable then.
Viel wichtiger ist doch das Endergebnis. Wenn man die Zeit mit solchen Kleinigkeiten vergeudet, hat man keine für die wichtigen Funktionen.
Ist ja so als ob man in einem Buch eine schöne Handschrift hat, aber der Inhalt zum Kotzen ist

Solange nicht wirklich Programmierfehler vorliegen und man nicht im Team programmiert, ist der Stil m.M.n. irrelevant.
Wichtig ist das Ergebnis das am Ende für den Anwender und den Support rauskommt. Das ist meine Meinung.

Und viel viel wichtiger als ein "schöner" Codestil ist eine lückenlose Dokumentation des Quellcodes.

Totale Zustimmung @dive26
Ich programmiere nun auch seit gut 20 Jahren. Der Stil ändert sich mit der Zeit gewaltig. Aber dass was sich bei mir massiv entwickelt hat, ist die Dokumentation. Auch habe ich vor jeder Funktion oder Inhalten, Klassen oder Abschnitten, eine wirklich umfangreiche Erklärung dessen, was der folgende Code bezwecken soll.

Der Grund, die Kommentare der ersten Programmierjahre sind zwar okay, aber das was ich mir zwischen den Zeilen dachte weiß man einfach nicht mehr, wenn man Jahre danach wieder mit dem Source konfrontiert wird. Besonders im Konsens mit verknüpftem Source. Also kurze Kommentare erklären schon mal die nächsten paar Zeilen Code, aber wozu ist der überhaupt gut, usw.

Und so habe ich angefangen, wirklich in vollen Sätzen zu beschreiben, was, wie und warum, etc. Ich habe oft sogar mehr Beschreibung als Quellcode. Das hilft immens. Während, und vor allem später mal.

@dive26
Wie wichtig gute Dokumentation ist, lerne ich grade beim durchstöbern alter Projekte.
Mit möglichst logische Code-Struktur,kleinen Methoden (max 30 Zeilen) und aussagekräftiger Variablenbenamung,
kann man schon eine gewisse lesbarkeit erzielen, aber dennoch sind Kommentare unerläßlich.
Allerding kann man es auch übertreiben, denn wenn ich den Code vor lauter Kommentaren nicht mehr sehe, ist das eher kontaproduktiv.

dive26 schrieb:

Es ist bei vielem so unnötig darüber überhaupt zu diskutieren. Beispielsweise ... If variable=true then oder if variable then.

Das sehe ich anders.
"Ich hätte gerne ein Glass nasses wasser" würde ich als schlechten Spachstil bezeichnen und läßt auf ein mangelndes Verständnis der grundlegenden Eigenschaften des Wassers schließen.
So verhält es sich auch mit Booleans, wenn man das grundlegende Prinzip wirklich verinnerlicht hat, ist If Not Bool, sogar besser (intuitiver) lesbar als If Bool = False, vorrausgesetzt der Variablenname ist sinnvol gewählt.

dive26 schrieb:

Und viel viel wichtiger als ein "schöner" Codestil ist eine lückenlose Dokumentation des Quellcodes.

hmm, hmm...

Man sollte sich aber hüten, viele Kommentare mit "vollständiger Dokumentation" zu verwechseln.
Code kann auch ohne jeden Kommentar vollständig dokumentiert sein, etwa wenn er gut benamt ist (und Problem-Darstellung und -Lösung nicht zu komplex).

Ich habe allerdings massenhaft Code gesehen, vollgemüllt mit Kommentaren wie

[Sub New] "erstellt eine neue Instanz von <Typ>".

So ein Kommentar ist keine Dokumentation, sondern ist Blabla.
Weil wer nicht selber weiss, dass eine Sub New eine neue Instanz erstellt, der sollte den Code eh nicht lesen dürfen.

Wie gesagt, viele müllen ihren Code mit derlei Gewäsch voll, und denken, sie hätten gut dokumentiert - was dann aber zum Verständnis des Codes 0 beiträgt.
Im Gegenteil: Vor lauter Grün-Text gehen die Codezeilen fast unter - zumindest Zusammenhänge werden schlechter erkenntlich.
ZB wenn eine Datei auf 1000 Zeilen aufgebläht ist, die nur 200 zeilen wirklichen Code enthält.

Meist wird vor lauter Grün-Schwafel auch die wirklichen Knackpunkte zu dokumentieren vergessen.

Nun gibt es aber Codierungsrichtlinien, von Firma zu Firma unterschiedlich. Überall jedoch war die Erzeugung des XML-Kommentars im Projekt angehakt.
Beim Konstruktor ist es dann sinnvoll sich auszulassen, wenn es mehrere Überladungen gibt, um dort knapp auf die Unterschiede bzw. den Aufruf einzugehen.
Je länger ich jetzt dabei bin, um so intensiver kommentiere ich meinen Code, weil ich in einem halben Jahr doch so einiges vergessen haben werde, was vor einem halben Jahr selbstverständlich war.
Da wird eben ein existierendes Gerät mit einigen Modifikationen bestellt, und die Hauptarbeit liegt, richtig, bei der Software.
Als ich den Code vor 3 Jahren übernommen habe, waren da ~< 1% Kommentarzeilen im Code, jetzt bin ich bei über 10%.

Bei folgendem bin ich mir nicht sicher, was ich davon halten soll.
Also, ich lese einen Wert aus der Registry und schreibe diesen auch wieder darin.
Nun stellt sich mir die Frage, ob ich das in einer Property abhandeln kann, oder das eher schlechter Stil ist.

Beispiel:

Ist generell schon in Ordnung, solange du ein paar Guidelines beachtest: docs.microsoft.com/en-us/dotne…esign-guidelines/property

Wichtig ist zb dass Getter keine Exceptions werfen. Wenn der Getter/Setter zeitintensiv ist, macht es auch meistens Sinn, Alternativen wie async zu nutzen um nicht zu blocken. Das geht mit Properties ja leider nicht.

@FormFollowsFunction Ich halte das für einen eher schlechten Stil, da Du auf die Registry zugreifst und das halt eine (Programm-)externe Ressource ist.
Eine Property soll sich ja verhalten wie eine Variable.

Die Frage ist, ist es wirklich wichtig, dass die Registry hier immer frisch ausgelesen wird, und der wert auch tatsächlich so schnell wie möglich wieder in die Registry zurück muss?

Im Falle dessen, dass du irgendwelche Settings in die Registry speicherst kannst du die Registry ja auch einmal zu beginn lesen, und später z.B. nur beim Click auf nen Speichern Button den aktuellen Wert der Property in die Registry schreibst. Dadurch hast du dann auch wieder zugriff auf Async usw.

Ich sehe das ganz genau so wie EaranMaleasi. Ich programmiere ausschließlich so, das ich egal welches Programm, Programmteile oder was auch immer, nach dem Prinzip aufgebaut ist, dass alles was dieses Programm so an Daten benötigt, zu Beginn in eine Klasse geladen wird.

Dann kann das Programm tun und lassen was es will. Die Werte werden als Variable in den Properties gehandelt. Dort können durchaus verschiedene Aktionen eingebettet werden (in den Properties), aber keinesfalls Datenzugriff nach aussen, das machen ausschließlich Speicherroutinen (oder Laden).

Das hat viele Vorteile, unter anderem...

• Wenn das Programm abstürzt oder abgewürgt wird, bleiben die Systemwerte unangetastet, und das Programm hinterlässt keinen undefinierten Zustand im System.
  
• Habe ich zum Beispiel dann in der Klasse die verschiedene Properties beherbergt, definiere ich auch immer eine Variable in der Klasse, ähnlich wie "SomethinEdited". Die bei jeder Variablenänderung In den Properties, auf True gesetzt wird!
  
  • Das hat wieder mehrere Vorteile, wenn der User etwa beenden will, kannst du fragen: "Daten wurden geändert, speichern?"
  • Bei etwa einem Button: "Reload Daten/Zustand oder was auch immer", kannst du das sofort tun, wenn Class.SomethingEdited False ist, andernfalls kannst du fragen: "Daten wurden geändert, Änderungen gehen verloren..."
  • Beim Programm beenden weißt du dann ja auch, ob etwas verändert wurde und wenn nicht, kannst du ohne zu fragen ob die Daten gespeichert werden sollen, beenden.
  • usw usw

(Die Speichern Routine setzt die SomeEdited Variablen der Klassen zurück)

...und es spricht ja nichts dagegen, wenn es dein Programm erfordert und eine derartige Änderung gleich in die Registry zurückgeschrieben werden sollte, das du dann im Zuge der Änderung der Property, gleich die Speichern Routine aktivierst! Ich hab dann auch immer so einen Parameter für die Speichern Routine wie "Force" oder "Fragen" ...