Codierungsstil für hohe Produktivität und weniger Fehler

Auf der diesjährigen JCrete Unkonferenz habe ich an einer sehr interessanten Session über Fehler und Codierungsstil teilgenommen, die von Cliff Click geleitet wurde (Die vollständige Diskussion finden Sie hier). Er begann mit seinen Erfahrungen als hochleistungsfähiger, professioneller Programmierer, über Entwicklungsgeschwindigkeit und das Verhältnis von Fehlern in neuem Code, überarbeitetem Code und fehlerbereinigtem Code und die Auswirkungen darauf auf den Codierungsstil.

Geschwindigkeit des Codierens und Fehlerquote

Seine Ansichten und Erfahrungen sind besonders interessant, da er große Teile der HotSpot JVM geschrieben hat, d.h. den meisten (wenn nicht allen) ihrer concurrency-bezogenen Code. Er führte eine statistische Analyse des JVM-Quellcodes und der von ihm und anderen Entwicklern geschriebenen Fehler durch. Seine Hauptbeobachtungen waren:

• Er produzierte 2x mehr Code (in derselben Zeit) als der zweitschnellste Entwickler (gemessen an Zeilen pro Zeiteinheit)
• Der zweitschnellste Entwickler schrieb 2x mehr Code als der dritte.
• Der Dritte … Sie verstehen das Bild

Er schrieb also so viel Code wie alle anderen Entwickler zusammen. Dies lag nicht nur daran, dass er schnell war, sondern auch daran, dass er viel neuen Code mit neuen Funktionen schrieb, wobei der Code auf explorativere Weise wächst und daher wahrscheinlich noch nicht hinsichtlich LoC minimiert ist.

Unabhängig von der Geschwindigkeit stellte er fest, dass

• Neuer Code führt 10x mehr Fehler ein als überarbeiteter Code
• Überarbeiteter Code führt 10x mehr Fehler ein als fehlerbereinigter Code
• Fehlerbereinigter Code führt Fehler ein (keine Überraschung hier :)

Als direkte Konsequenz fügte er hinzu, dass er nicht nur den größten Teil des Codes schrieb, sondern natürlich auch die meisten Fehler verursachte.

Natürlicher Codierungsstil

Während seiner Karriere als Entwickler entwickelte er - wie ich und die meisten Entwickler - seinen eigenen Codierungsstil, indem er anderen Entwicklern beim Codieren zusah, den Code anderer Entwickler las und herausfand, was für ihn am besten funktioniert und was nicht. Er sagt, dass sein Codierungsstil am besten für ihn funktioniert, aber wahrscheinlich nicht für andere am besten geeignet ist. Aber er kann am schnellsten - oder am produktivsten arbeiten, wenn er in seinem eigenen Codierungsstil schreiben kann.

So entwickelt ähnlich wie bei einem Handschriftstil jeder gute Entwickler im Laufe der Zeit seinen eigenen Codierungsstil, in dem er oder sie am produktivsten arbeiten kann. Die verbleibende Diskussion drehte sich um den Einfluss des Codierungsstils auf das Einführen oder Verhindern von Fehlern - darauf komme ich gleich zurück. Aber zuvor ein kurzes Zwischenspiel über die

Werte und Nicht-Werte des Codierungsstils

Die Hauptfrage in Bezug auf den Codierungsstil ist die nach dem Wert. Laut Wikipedia ist das Hauptziel von Code-Konventionen, die Wartungskosten zu senken. Dies liegt daran, dass

• Die Lesbarkeit und Verständlichkeit verbessert wird und daher die Zeit zum Lesen und Verstehen verringert. Dies wirkt sich auf die Wartung, aber auch auf die Entwicklung aus.
• Verringern der Zeit zum Lesen der Änderungshistorie des Codes, was oft Teil der Wartungsaktivität (oder Code-Archäologie) ist
• Verringern der Fehlerquote, da Fehler leichter zu erkennen sind

Im Gegensatz dazu werden manchmal die folgenden Argumente als Grund für Code-Konventionen angeführt, die jedoch nicht sehr unterstützend sind, da diese Argumente allein kein Geschäftsziel erfüllen.

• Größe. Manche mögen argumentieren, dass in einigen Fällen (JavaScript) der Codierungsstil zu kompakterem Code führen kann und daher weniger Bandbreitenverbrauch aufgrund der reduzierten Größe, aber da es auch Werkzeuge zum Kompaktieren/Minimieren dieses Codes gibt, stimme ich diesem Argument nicht wirklich zu.

• Konsistenz. In dem Artikel “Warum der Codierungsstil wichtig ist” schrieb der Autor, dass der Codierungsstil für konsistenten Code sorgt, ohne zu erwähnen, warum dies notwendig ist. Konsistenz selbst ist kein Geschäftswert. Wenn Konsistenz zu reduzierten Entwicklungs- oder Wartungskosten führt, wäre das Argument gültig. Aber das ist sicherlich nicht immer der Fall. Dennoch, Konsistenz könnte je nach Kontext ein gültiger Grund sein. Zum Beispiel schätzen Apache Software Foundation-Projekte die Gemeinschaft am meisten. Dies bedeutet auch, dass die Gemeinschaft nicht nur Eigentum am Code hat, sondern auch, dass viele Menschen zur Codebasis beitragen. Um offen für die Gemeinschaft zu bleiben, ist ein gemeinsamer Codierungsstil zur Erreichung von Konsistenz wichtig, während die Produktivität jedes einzelnen Entwicklers eine geringere Priorität hat. Dennoch gibt es keine allgemeine Regel, dass _alle_ASF-Projekte dieselben Codekonventionen einhalten müssen, die meisten Projektgemeinschaften entwickeln ihren eigenen Stil, während sie sich an einem gemeinsamen Satz von Basisregeln orientieren, die von Suns Codekonventionen für die Java-Programmiersprache abgeleitet sind. Zum Beispiel: Apache Commons, Apache Felix

Codierungsstil und Fehler

In seiner Session konzentrierte sich Cliff auf den oben genannten dritten Wert, den Einfluss auf die Fehlerquote, und sein Hauptargument war, dass man Fehler in Code, der schneller zu lesen und zu verstehen ist, leichter erkennen kann, während die Rate der Fehler pro Aussage gleich bleibt.

Zu diesem Thema kann ich den Artikel Codierungsstil: Knapp vs. Ausführlich für ein tieferes Verständnis der Unterschiede und Auswirkungen von knappem und ausführlichem Code empfehlen.

Clean-Code-Regeln besagen, dass eine Methode nicht mehr als 10 Zeilen Code enthalten sollte - oder wie Martin Thompson es formulierte

Aber ich denke, es ist weniger eine strikte Regel, sondern eher eine Richtlinie, der Entwickler folgen sollten, aber es ist erlaubt, Ausnahmen von dieser Regel zu machen, abhängig vom Kontext. Wenn eine Methode 12 Zeilen statt 10 benötigt, während sie immer noch eine hohe Kohäsion hat, dann tun Sie es.

Aus meiner Erfahrung kann ich empfehlen

• Halten Sie die Methoden kurz und prägnant für ein besseres und schnelleres Verständnis (Martins Handregel)
• Halten Sie die Kohäsion der Methode hoch
• Jede Methode kann so viele Zeilen haben, wie erforderlich, aber nicht mehr.

Fazit

Für mich war die Session äußerst wertvoll und aufschlussreich. Ich habe in meiner Karriere verschiedene Codierungsstile gesehen. Einige davon waren leicht zu folgen und haben mich nicht verlangsamt, andere fand ich mehr als einmal eine echte Last, zum Beispiel: keine leeren Zeilen, automatische Entfernung ungenutzter Felder (nicht Strg+S bei unfertiger Arbeit!), keine Inline-Kommentare, keine Ternär-Operatoren, Kommentare nur auf Deutsch (ernsthaft!?), Ausnahmeklassenbezeichnungen auf Deutsch und viele mehr. In meinem Code versuche ich so prägnant wie möglich zu sein und ich bevorzuge einen knapperen statt ausführlicheren Stil.

Meine Empfehlung für eine Codierungskonvention ist, dass sie vor allem eine Richtlinie sein sollte, die Entwickler unterstützt und nicht einschränkt.

• Knapper Code: leichter auf einen Blick zu verstehen, einfacher, konzeptionelle Fehler zu erkennen
• Ausführlicher Code: benötigt mehr Zeit zum Lesen und Verstehen, verringert die Produktivität
• Kontrollfluss: machen Sie den Kontrollfluss offensichtlich und gut lesbar

Vermeiden Sie Diskussionen über:

• Tabs vs Leerzeichen: sie fügen keine Fehler hinzu, diskutieren Sie gar nicht
• Kommentare: sie fügen keine Fehler hinzu, nur nützlich, wenn sie zusätzliche Informationen bereitstellen, sonst weglassen
• Leerzeilen: sie fügen keine Fehler hinzu, sind ein gutes Mittel zur Trennung von Konzepten

Ich will nicht behaupten, dass Teams keinen gemeinsamen Codierungsstil haben sollten. Meine Ansicht dazu ist, dass ein Team nicht zu viel Zeit mit der Aushandlung eines gemeinsamen Nenners verbringen oder Regeln durchsetzen sollte, die die Hälfte der Entwickler verlangsamen, sondern stattdessen sollte das Prinzip der geringsten Einschränkung anwenden und etwas gesunden Menschenverstand gebrauchen.