Clean Code Prinzipien – lohnt sich der Aufwand im Studienprojekt wirklich?

Hallo Markus, das Thema kenne ich gut, bei uns in der Wirtschaftsinformatik taucht Clean Code ständig in den Programmier- und Softwareentwicklungsmodulen auf. Deine Beobachtung mit der Pause trifft den Kern eigentlich schon ziemlich genau.

Ich mache das mittlerweile fast wie ein Experiment mit mir selbst: Wenn ich ein Projekt abgebe und es nach 3-4 Wochen wegen Korrektur oder Rückfragen nochmal aufmachen muss, merke ich sofort, ob ich sauber gearbeitet habe oder nicht. Bei schlecht benannten Variablen wie temp2 oder x brauche ich teilweise 20 Minuten, um den eigenen Gedankengang zu rekonstruieren. Bei sprechenden Namen und kleinen, klar abgegrenzten Funktionen reicht ein kurzer Blick.

Ein paar Erfahrungswerte von mir:

• Sprechende Namen kosten kaum Mehraufwand, wenn man sie sich direkt beim Schreiben überlegt statt hinterher umzubenennen.
• Kleine Funktionen zahlen sich vor allem beim Debuggen aus, weil man Fehler viel schneller eingrenzen kann.
• Ein kurzer Kommentar über komplexeren Logikblöcken ersetzt oft 10 Minuten Grübeln beim zweiten Lesen.

Zur Bewertung: Bei uns wird das in den Rubrics meistens explizit unter "Code-Qualität" oder "Wartbarkeit" gelistet, also kein Nice-to-have, sondern ein fester Punkteblock. Insofern lohnt sich der Aufwand doppelt: für die Note und für dein zukünftiges Ich, das in sechs Wochen vor dem eigenen Code sitzt und sich fragt, was da eigentlich passiert.

Hallo zusammen, kann das aus der Wirtschaftsinformatik-Ecke nur bestätigen, Daniel hat das mit den Rubrics schon gut beschrieben. Bei uns läuft das ähnlich: Wartbarkeit ist ein eigenes Lernziel, kein netter Bonus. Das hat auch einen fachlichen Hintergrund, der über die reine Benotung hinausgeht.

In der Praxis arbeitet man so gut wie nie allein an Code, und selbst wenn doch, übernimmt irgendwann jemand anderes die Wartung, oder man selbst nach Monaten, wie ihr beide schon beschrieben habt. Deshalb wird Clean Code im Studium oft schon früh trainiert, obwohl die Projekte klein und einsam sind, damit man es sich gleich zur Gewohnheit macht statt es später mühsam umzulernen.

Zur Bewertung bei uns: Es gibt meistens Punkte für

• sprechende Bezeichner (Funktionsnamen sollen sagen, was sie tun, nicht wie)
• Single-Responsibility auf Funktionsebene, also eine Funktion macht genau eine Sache
• konsistente Formatierung und sinnvolle Modularisierung statt einer "God-Function"

Ein Merksatz, den ich mir gemerkt habe: Code wird viel öfter gelesen als geschrieben. Das rechtfertigt auch, beim Schreiben etwas mehr Zeit zu investieren. Typischer Anfängerfehler ist übrigens, Clean Code erst am Ende "drüberzubügeln" statt von Anfang an sauber zu strukturieren, das kostet am Ende mehr Zeit als es spart.