Coding Codex //2364

Derzeit bin ich dabei, unsere Kodierrichtlinien zu überarbeiten. So richtig motiviert bin ich nicht, aber es gibt einiges anzupassen, zu aktualisieren und zu verbessern. Das lässt sich ganz gut daheim erledigen. Etwas dringenderes gibt es derzeit nicht zu tun, zumal ich nicht gerade jetzt unter diesen ungewissen Bedingungen ein größeres Projekt beginnen will.

Ich lege Wert auf sauberen Code, der weitgehend selbsterklärend ist. Das bedeutet unter anderem, „sprechende“ Variablen- und Funktionsnamen zu verwenden (lokale Hilfsvariablen wie Laufvariablen ausgenommen, da reicht ein i, j, k, m oder n).
Manches ist Geschmacksache, aber ich persönlich ziehe einen kompakten Code vor. Das bedeutet, dass ich u.a. nicht übermäßig viele Zeilen möchte, die nur aus einem einzigen Zeichen bestehen. Eine schließende Klammer am Funktionsende ist OK, aber darüber hinaus erhöht so ein Vorgehen nur die Anzahl der Codezeilen, aber nicht der Instruktionen. Um einen Code mit vielen kurzen Zeilen zu überblicken, reicht eine einzelne Bildschirmseite oft nicht aus, und man muss vertikal scrollen, scrollen, scrollen. Deshalb finde ich es i.A. besser, den Code enger zusammenzuschreiben – ein Prinzip, das man aber natürlich auch nicht überstrapazieren sollte. Es geht mir nur um Richtlinien zur Orientierung oder als Empfehlung, von denen man in begründeten Fällen Abstand nehmen darf.

Ähnlich ist es mit Kommentaren. Manche Programmierer kommentieren jeden Pipifax, und machen dadurch den Code schwerer verständlich, als er ohne sie wäre. Bei Verwendung „sprechender“ Namen, muss man nicht noch jedesmal eine Beschreibung daneben schreiben. Das bläht die Sourcen nur unnötig auf. Wirklich wichtige Kommentare fallen dadurch nicht mehr auf, da man sie dann leicht überliest.
Also Kommentare nur dann, wenn etwas außergewöhnliches dies erfordert, so dass Besonderheiten auch noch zwei Jahre später für einen anderen Entwickler nachvollziehbar sind. Oder wenn die Bedeutung des Codes, insbesondere bei aufwendigeren Algorithmen, nicht unmittelbar ersichtlich ist.
Es gibt durchaus noch etliche Stellen, an denen ein Kommentar sinnvoll und zweckmäßig ist. Bloß gegen solche Kommentarinflationen, bei denen man vor lauter Kommentaren den Code (trotz Syntax Highlighting) nicht mehr sieht, setze ich mich zur Wehr.

Außer der Häufigkeit von Zeilenumbrüchen ist unter Programmierern immer wieder ein hitzig diskutiertes Thema, wie weit man bei verschachteltem Code einrücken sollte.
Ich persönlich empfinde zwei Blanks als angenehm. Diese Einrückungstiefe genügt, um eindeutig als solche wahrgenommen zu werden, andererseits fransen die Zeilenanfänge nicht zu sehr aus. Wer lieber drei oder gar vier Leerzeichen einrücken möchte, darf das allerdings. Da bin ich tolerant. Eine noch größere Einrückungstiefe dulde ich dagegen nicht. da hat man sonst ganz schnell nur noch sehr wenige Zeichen pro Zeile übrig.
Und dann gibt es noch die Entwickler, die algorithmisch erst mit mehreren Leerzeichen Einrückung beginnen, um dann bei tieferer Verschachtelung weniger Leerzeichen zu benutzen (warum erinnert mich das jetzt an die Kommentare bei WordPress?).

Moderne Compiler erlauben teils exotische Konstruktionen, die recht kryptisch erscheinen können. Dadurch können mit einer einzigen Anweisung komplexe Operationen durchgeführt werden.
Nicht alles, was machbar und erlaubt ist, sollte man auch umsetzen. Was der eine Programmierer beherrscht, ist für einen anderen vielleicht nicht so selbstverständlich, und schon schleichen sich Fehler ein, die sich kaum noch debuggen lassen.
Code sollte so klar und eindeutig formuliert sein, dass nicht nur der Compiler ihn versteht, sondern auch ein noch unerfahrener Programmierer. Im Zweifel mal lieber eine Variable mehr deklarieren, als eine zu wenig, oder zusätzliche Befehle einfügen, wenn sie den Code insgesamt leichter erfassbar machen.
Und ich mag, ehrlich gesagt, diese Inline-Deklarationen nicht. Später ist dann gar nicht mehr nachzuvollziehen, woher eine bestimmte Variable stammt, und in welchem Scope sie gültig ist. Auch so etwas kann eine Fehlersuche erheblich erschweren.

Dann gibt es auch noch so ein paar Spezialisten, die wiederholt if-Abfragen der Art if (!$Q == FALSE) schreiben. Das ist grausam! So etwas erlaube ich nicht. Wenn ich zukünftig solche Codezeilen entdecke, muss der Verursacher einen symbolischen Beitrag zur virtuellen Kaffeekasse entrichten.

Über Anne Nühm (breakpoint)

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

6 Antworten zu Coding Codex //2364

  1. keloph schreibt:

    das sind alles durchaus geschmacksfragen. was nicht dem geschmack anheim gestellt werden darf ist die nachvollziehbarkeit und die lesbarkeit. bei uns gab es vor 30 jahren die regel, dass der kommentar 50% ausmachen soll und die komplette logik beschreibt. auch waren bestimmte namenskonvention en gleichgeschaltet.

    Gefällt 1 Person

    • Ja, vieles ist Geschmacksache. Da hat jeder Programmierer einen etwas anderen Stil.
      Um die Nachvollziehbarkeit des Codes (auch noch in ein paar Jahren, wenn der Autor nicht anwesend ist) zu gewährleisten, ist es zweckmäßig, dennoch einige gemeinsame Standards einzuhalten.

      50% Kommentare sind mir eindeutig zu viel. Wenn ich mich auf eine bestimmte Menge als Obergrenze festlegen müsste, wären das vielleicht 20%, allerhöchstens 30% für einen normalen Code, nur bei besonders diffizilen Sachen auch mal deutlich mehr.

      Gefällt 1 Person

  2. mkuh schreibt:

    Guten morgen,
    lässt du deine Regel automatisch Prüfen?
    inzwischen gibt es da ja einiges an Tools

    Viele Grüße

    Mkuh

    Gefällt 1 Person

    • Solche Tools setzen wir höchstens mal sporadisch ein.
      Es geht darum, dass z.B. in Code Reviews der Code auch für einen anderen Entwickler noch gut lesbar und begreiflich ist.
      Oder wenn ich mir die Sourcen anschaue, und mir fallen manche Stellen (unangenehm) auf, muss der zuständige Mitarbeiter sich ggf. dafür rechtfertigen.

      lg Anne

      Liken

  3. claudius2016 schreibt:

    Ich kenne einen Kollegen, der über den Code ein (aus meiner Sicht) Tarnnetz aus Kommentar legt. Um den Code lesen zu können, muss ich seine Kommentare immer löschen.

    Gefällt 1 Person

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.