Softwaretechnik, 11.3. Implementierung

Material für die Softwaretechnik Vorlesung, Bernhard Rumpe

Abschnitt 11.3. Codingstandards: Stilfragen der Codierung

  • Waren Sie auch schon mal unglücklich über die
    • schlechte Einrückung von Programmen,
    • hyperkomplexe Ausdrücke oder Statements,
    • unverständliche Funktionsnamen oder
    • irreführende oder fehlende Kommentare ihrer Kollegen oder Kolleginnen und haben erstmal alles reformatiert und umbenannt?

  • Dies ist kein untypisches Phänomen, wenn Entwickler:innen das erste Mal zusammenarbeiten und sich dabei erst kennen lernen müssen.

  • Neben dem korrekten und optimalen Programm ist es für die gemeinsame Arbeit im Team, aber auch für die spätere Wiederverwendung von Code im eigenen Projekt wichtig, einen gemeinsamen Stil für die Entwicklung des Programms zu nutzen. Codierungsrichtlinien gibt es einige, die jeweils spezifische vor und Nachteile besitzen. Je nach Unternehmen, Sprache und Projektkultur kommen unterschiedliche Vorstellungen und Regeln zum Einsatz.

  • Wichtig ist: es gibt solche Richtlinien im Projekt und alle halten sich daran!

  • In den nachfolgenden Folien wird ein für Java üblicher Satz an Regeln vorgestellt, der in den genannten Literaturstellen noch deutlich verfeinert wird. Diesen Regelsatz dürfte man in der Praxis relativ häufig antreffen. Er ist nicht der Einzige, aber er wird auch von einschlägigen IDEs und Editoren mit automatisierten Layout-Funktionen unterstützt.

  • Wenn Sie noch eher selten versucht haben fremden Programmcode zu verstehen: Nehmen Sie sich die Zeit und versuchen Sie rauszufinden was dieses Programm tut.

  • Überlegen Sie vor allem: welche Verbesserungen würden Sie den Entwicklern vorschlagen? Also: Was würden Sie anders machen?

  • Liebe Studierende: Wenn Sie Schwierigkeiten haben das Programm zu verstehen (und das wäre nicht untypisch, denn ich hatte es auch), dann verstehen Sie vielleicht warum wir bei der Erarbeitung von studentischen Lösungen nicht nur auf die Funktionsfähigkeit, sondern insbesondere auch auf die Verstehbarkeit des Codes Wert legen. Die Ausarbeitung hat ihren Anteil diesen Zugang um Code zu finden, aber der lesbare Code selbst gehört auch zum Ergebnis.

  • Ein Programm, das nur geschrieben wird um einmal zu laufen ist eher selten und von wenig Wert. Praktisch alle Programme werden permanent weiterentwickelt, an neue Inputs und Umgebungen angepasst, neue Funktionalitäten hinzugefügt, etc.

  • Lesbarkeit ist ein hohes Gut für ein Programm.

  • Programme werden wesentlich öfter gelesen als geschrieben. “Aus der Sicht der Leser:innen schreiben” gilt daher nicht nur für Romane, Essays und Kurzgeschichten, sondern auch für Programme.

  • Wir können auch einen Agenten einsetzen, um uns das Programm erklären zu lassen. Tatsächlich kann man es auch von einem Agenten stilistisch verbessern lassen und mit Erklärungen im Text versehen lassen.

  • Auf dieser und der nächsten Folie findet sich jedenfalls eine Erklärung, die ChatGPT im Jahr 2025 geliefert hat auf Basis des Prompts “explain the following Java program”, in der es systematisch zunächst eine Erklärung abliefert, dann die wesentlichen Elemente beschreibt, die in dem Code auftauchen, und auch erkennt, dass ein Kernelement eine Berechnungsschleife ist.

  • Auch 2025 hat ChatGPT schon korrekt erkannt, dass es sich um ein kleines Programm aus der Finanzwelt handelt und den Zweck korrekt beschrieben.

  • Im weiteren Verlauf der Erklärung wir zunächst darüber nachgedacht, ob die Berechnung korrekt ist. Interessanterweise hatte damals (2025) ChatGPT hat noch einen möglichen Fehler im Code falscherweise identifiziert, allerdings eine äquivalente Lösung als Umformulierung angegeben. Das würde heute so wahrscheinlich nicht mehr passieren, weil die KI-agenten sicherheitshalber noch mal verifizieren, ob die beiden angegebenen Formeln im Code und die alternativ angegebene Formel nicht doch äquivalent sind.

  • Interessant sind auch die Überlegungen zu den genutzten Klassen (“Console”) und Methoden sowie der Hinweis auf potenziell nicht adäquat abgefangene Eingabefehler.

  • Das Ergebnis des Experiments: ChatGPT ist sehr wohl in der Lage, ein schlecht geschriebenes und schlecht aufbereitetes Programm zu verstehen und gegebenenfalls zu verbessern. Was ChatGPT nicht kann, ist den Intent des Programmierers zu erkennen, weil dieser nicht abgebildet ist. Es hätte ja sein können, dass dieser Code, ein Array sortieren soll?

  • Diese Form der Verbesserung bekommt eine IDE automatisch hin, denn hier wurde nur Layout angepasst.

  • Den Sinn des Programms kann die IDE leider nicht erfassen, weshalb die Variablennamen weiterhin nicht sprechend oder hilfreich sind.

  • Wenn man einen SE-Agenten bittet dann kann dieser durchaus auch mit sprechenden Variablen und Methodennamen versehen. Das hat die vorangegangene Analyse mit ChatGPT gezeigt.

  • Einrückungstiefe zwei hat sich als hilfreich erwiesen:
    • Zwei Spaces sind schnell gedrückt
    • 4 Spaces: da muss man schon zählen und das lenkt vom Inhalt ab
    • Nur ein Space je Einrückung wirkt etwas unübersichtlich bei etwas länglicheren Code-Stücken
    • Den Tabulator kann man zum Einrücken verwenden, aber der Editor sollte die Zeichen expandieren, denn nicht alle (eventuell auch in der Zukunft verwendeten) Editoren verwenden dieselbe Tabulator-Einrückung. Das führt zu unleserlichem Code, besonders falls sowohl Tabs als auch Spaces verwendet werden.
  • Können Sie den Code von vor einem Jahr noch gut verstehen? Sie schreiben ihn eventuell ja auch für sich selbst.

  • Wir können Agenten wie gezeigt benutzen, um Coding Guidelines einzuhalten. Das funktioniert gut.

  • Sorgen wir aber selbst für das Einhalten von Coding Guidelines, so kann ein Agent diese benutzen, um zum Beispiel Programmierfehler zu identifizieren, die zwar das richtige einrücken, aber die falschen geschweiften Klammern identifizieren.

  • Es sind aber vor allem semantisch sinnvolle Namen, also die Bezeichnerwahl Die den Softwareagenten weiterhelfen. Insbesondere führen semantisch verkehrte Namen von Softwareagenten gerne in die Irre.

  • Softwareagenten sind auch flexibel: Man kann Ihnen sehr wohl unterschiedliche Programmierstile beibringen. Auch durchaus unkonventionelle Programmierstile. (Aus Software Engineering Gründen ist dies aber nicht zu empfehlen). Immerhin wird diese Flexibilität von Firmen genutzt, um firmenspezifische oder sogar projektspezifische Guidelines durchzusetzen und noch besser zu etablieren.

  • Guten Stil beinhaltet auch weiterhin Kommentierung, aber allerdings auch gerne weiterhin kompakt und auf den Punkt gebracht.

  • Das menschliche Auge kann Text am schnellsten erfassen, wenn er in Spalten mit 72 Zeichen Breite umgebrochen wird. Zeitungen zum Beispiel sind so gebrochen.

  • In Analogie sollten überlange Methodenköpfe eher frühzeitig umgebrochen werden.

  • Wer hat nicht schon mal in Zeile 03 ein weiteres Statement hinzugefügt, das von der Bedingung aus Zeile 01 abhängig ausgeführt werden sollte, jedoch immer ausgeführt wurde.

  • Besonders sicherheitskritische Codierungsrichtlinien erfordern sogar, dass immer geschweifte Klammern definieren werden.

  • Die Mathematik und auch die Physik hat gerne einbuchstabige Variablen verwendet, weil nach Konvention Buchstaben immer einen bestimmten Typ hatten. Beispiel x steht für die x-Koordinate, n für eine natürliche Zahl, l für eine Länge.

  • Wir in der Informatik verwenden viel zu viele Variablen und Funktionen und müssen daher mit anderen Konventionen arbeiten. Außerdem hilft uns natürlich die Autovervollständigung der Editoren um lästige Tipparbeit zu reduzieren. Andererseits gilt: aus der Sicht des Lesers schreiben, ihr Editor hat zwar Hover-Funktionen, aber gilt dies auch für den Editor des Lesers oder den Papierausdruck?

  • Bei uns gilt: Langer Name: langer Scope; kurzer Name: kurzer Scope. Sonst sucht man zu lange nach der Definitions- und Erklärungsstelle für die Namen.

  • Zu den Beispielen (nicht alle sind schlecht):

    • CustomerName klingt wie eine Klasse,
    • customerName wie ein Attributname.
    • Großbuchstaben in der Mitte des Wortes, wie in customerName, heißen Camel Case und dienen tatsächlich der Lesbarkeit. Man gewöhnt sich daran.
    • Methodennamen beinhalten meist ein Verb, z.B. openAccount() oder isAccountOpen()
    • Konstante werden gerne komplett in Großbuchstaben geschrieben.

  • Die fachliche Aufgabe einer Variable in ihrem Namen darzustellen macht den Code viel lesbarer. Man muss auch nicht dieselbe Variable für verschiedene Zwecke wiederverwenden, Speicherplatzoptimierung macht heute der Compiler. Der Typ einer Variable wird auch aus dem fachlichen Zweck klar und eine starke Typisierung einer (guten) Programmierprache sichert die Verwendung auch ab.

  • Wenn der Code zu kompliziert oder lang wird: es gibt immer die Möglichkeit Teile in eigene Methoden auszulagern. das verbessert übrigens auch die Testfähigkeit enorm.

  • Je besser der Code lesbar ist, umso weniger ergänzende Kommentare sind notwendig. Dann muss auch nicht jede Methode dokumentiert werden.

  • Wenn das wirklich empfehlenswerte javadoc zum Einsatz kommt, dann wird aus den Kommentaren entsprechende Dokumentation generiert, was noch mal eigene Richtlinien zur Dokumentation mit sich bringt.

  • Das ist ein typischer Header für eine Klasse aus der primären Bibliothek für Java, java.util.*. Das kann man so machen. Es liest sich auf jeden Fall verständlich und ist javadoc geeignet.

  • Entwurfsmuster sind eins der wesentlichen Hilfsmittel um gute Software in wiederverwendbarer Form zu erstellen. Ein Entwurfsmuster in wiedererkennbarer Form einzusetzen bedeutet, das dem Leser viel Leseaufwand erspart bleibt.

  • Factory und die in der Vorlesung diskutierte Variante des Singleton helfen um das Problem mit den statisch fixierten Aufrufen loszuwerden und damit Tests besser zu definieren. Die Factory kann beim Testen eben auch Dummies erzeugen, der Konstruktor-Aufruf nicht.

  • Unbedingt!

  • Es gibt noch einiges zu besprechen, aber manchmal reicht es auch sich zu einigen, wenn man die Ungereimtheiten und Probleme im Team bemerkt.

  • Die Nutzung eines Versionssystems wie subversion (svn) oder git ist mittlerweile eh klar, oder?

  • Ein Ticketsystem und ein Tracking aller offenen Punkte sowie gemeldeten Bug’s ist aber heutzutage Standard und deshalb am besten gleich von Anfang an zu nutzen.

  • Wir hoffen, die Richtlinien helfen Ihnen und Ihre Team-Mitglieder halten sich an gemeinsam beschlossene Richtlinien.

Stay informed about courses and theses!

Join our mailing list to receive the latest updates and announcements directly in your inbox.

Subscribe to se-teaching