Softwaretechnik, 8.3. Implementierung

Material für die Softwaretechnik Vorlesung, Bernhard Rumpe

Abschnitt 8.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.

  • 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.

  • 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.

  • 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.

Join our mailing list for updates regarding courses and theses: