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

  • VB.NET

Es gibt 264 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    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.
    Liebe Grüße
    Roland Berghöfer

    Bei der Entwicklung meiner Anwendung(en) steht nicht "Code nach .NET Lehrbuch" im Vordergrund, sondern eine stabile und brauchbare Anwendung die der Anwender ordentlich verwenden kann. Usability für den Kunden und Supportbarkeit beim Kunden stehen an oberster Stelle. Das spiegelt sich auch in meinen Fragen und Antworten wider. Bitte verzeiht, dass meine VB.NET Quellcodes etwas VB6-lastig sind aber das ist für das funktionierende Endergebnis nicht wirklich relevant.
    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. :S
    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%.
    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).
    VB-Fragen über PN / Konversation werden ignoriert!