3 Grundregeln für sauberen Code

Karriere TipsArbeitsleben

Developer setzen Geschäftsideen in Code um. Manchmal vergisst man aber die Hexenküche wieder etwas aufzuräumen – Clean Code ist in diesem Fall das passende Stichwort! Applications, welche nach Clean-Code-Regeln geschrieben wurden, sind einfach zu skalieren und angenehm zu bearbeiten und weiter zu entwickeln. Entsprechende Benennung von Variablen, Methoden, Klassen sowie die Reihenfolge der Anwendungsebenen ist sehr wichtig.

Wozu denn überaupt?

Die Hauptidee ist, dass jeder Mensch der je deinen Code zu Gesicht bekommen wird, möglichst schnell erkennen soll, was deine Absicht war und was der Code tut. Der Code soll sich selbst erklären. Klingt doch ganz gut, oder? Aber stellen wir doch mal die Frage: warum eigentlich? Warum interessiert es uns überhaupt, dass der Code selbsterklärend ist?

Vor der Antwort kannst du dich auch mal selbst fragen: "Wie viel Zeit verbringe ich mit dem Schreiben von Code und wie viel Zeit verbringe ich mit dem Lesen von Code?"

Wenn du mehr Zeit mit Schreiben verbringst – wow, Hut ab! Denn die meisten Entwickler verbringen weitaus mehr Zeit mit dem Lesen von Code als wie mit dem Schreiben. Und genau aus diesem Grund ist es essentiell sicherzustellen, dass Code einfach zu verstehen und angenehm zu lesen ist. Es herrschen treten weniger Missverständnisse auf und die generelle Arbeit läuft glatter.

Es ist noch kein Meister vom Himmel gefallen und anfangs schreibt auch niemand sauberen Code, der Code entwickelt sich und ändert sich. Deshalb ist es sehr wichtig zu überdenken, was und wie du programmierst. Pair-Programming und Feedback von Teamkollegen helfen sehr viel hiermit und verbessern so die Qualität deiner Arbeit. Wie gesagt, dies ist ein kontinuierlicher Prozess, wo ständig ausgebessert und überarbeitet werden muss. Schreib einen Codeentwurf, schau ihn dir an und versuche dann ihn sauberer zu überarbeiten. Es ist auf gewisse Weise wie die Arbeit eines Bildhauers - das Meisterwerk entsteht durch Reduzierung Gesamtmasse.

Pair Programming

Arbeiten zu zweit verbessert die Codequalität und die Arbeitsgeschwindigkeit und bietet zwei Entwicklern die Möglichkeit, Wissen und Ideen miteinander zu teilen. Das Ergebnis wird besser sein als es eine Person alleine erreichen könnte, und Lösungen die während der Diskussion entstehen, sind meist viel besser durchdacht und ausgearbeitet.

Pair Programming sieht im Grunde so aus: Zwei Devs sitzen an einem Schreibtisch, eine Person schreibt ein kleines Stück Code und die zweite Person kommentiert sie sofort – wie ginge es alternativ, kann man etwas einfacher formulieren, etc. Pair Programming ist auch eine gute Möglichkeit das Wissen zwischen erfahrenen Kollegen zu teilen. Es geht in erster Linie um Brainstorming, wie sich zwei Denkprozesse gegenseitig beeinflussen, während geschrieben und gleich das Geschriebene analysiert wird.

Einige Richtlinien für sauberen Code:

1. Weniger ist mehr

Wenn es um das Schreiben einer Software geht, kann es am Anfang vorkommen, dass viel mehr geschrieben wird, als wie tatsächlich notwendig. Beispielsweise gibt es manchmal Variablen, die nicht benötigt werden, große „if“ Blöcke, die man streamlinen könnte – solche Sachen.

Irgendwann ist es dann gesund, wenn man den Code etwas schlanker macht. Die unnötigen Variablen los wird. Man kann auch Kommentare entfernen, schließlich sollte der Code ja so selbsterklärend wie möglich sein.

2. Refactoring

Wie groß sind deine implementierten Funktionen? Wenn sie mehr als 20 Zeilen, viele if-Statements, verschachtelte Schleifen usw. enthalten, sollte man mal einen Schritt zurück gehen. Versuche, dein Geschriebenes so umzuformen, dass auf einen Blick klar sein kann, was die Funktion tut, ohne die Logik dahinter genau analysieren zu müssen.

Warum überhaupt Refactoring? Weil es hilft, die Struktur einfacher zu halten und zu lesen. Es mag zwar anfangs auch etwas verwirrend sein, wenn Funktionen nur kurz sind, aber dafür wiederum 10 neue Funktionen aufrufen. Mehrere kleine Code-Häppchen sind aber weitaus besser bekömmlich, als wie wenn alle diese Funktionen zusammengepackt in einem riesigen, undurchsichtigen Haufen sind.

3. Klingende Namen

Es lohnt sich, etwas Zeit damit zu verbringen, den richtigen Namen für eine Klasse, Funktion oder Variable zu finden. Das spart unseren Kollegen – und in Zukunft vielleicht auch uns selbst – viel Zeit. Keine undurchsichtigen Abkürzungen verwenden, Namen sollten einfach und selbsterklärend sein. Beispielsweise könnte „usersAction“ ein unklarer Name sein. Um zu wissen, was „usersAction“ bedeutet, muss man wahrscheinlich in die Beschreibung der Funktion schauen. Im Gegensatz dazu könnte die Funktion mit dem selbsterklärenden Namen "saveUserInDataBaseAndSendAnEmail" sein. Dieser Name gibt genau an, was geschieht. Und im Inneren dieser Funktion könnten dann – gemäß Punkt 2. Refactoring – Unterfunktionen mit so Namen wie „saveUserInDataBase“ oder „sendEmailToUser“ zu finden sein.

• Für Variablen: Der Name sollte angeben, welche Daten darin enthalten sind oder welcher Dienst sich dahinter versteckt.
• Für Funktionen: Der Name sollte im Wesentlichen das ausdrücken, was geschieht.
• Für Klassen: Der Name sollte den größeren Teilbereich des Projektes beschreiben. Also beispielsweise so Teile der Systemlogik wie „Zahlungen“, „Rechnungen“, usw. Wenn Klassen länger als wie etwa 200 Zeilen werden, kann man allmählich darüber nachdenken, sie neu aufzuteilen.

Und um es noch einmal zu betonen: Sauberer Code bedeutet Vorteile! Angenehme Arbeit, weniger Stress, weniger Unit Tests, einfaches Debuggen und bessere Qualität.

Es wird fast jeder Entwickler – welcher schon das eine oder andere Projekt hinter sich hat – kennen, dass wirrer Code viel Zeit, Nerven und Energie kostet. Das liegt nicht daran, dass man schlechter Entwickler ist, sondern vielmehr dass man teilweise ewig lange zum Entziffern und Verstehen des Codes braucht. Das ist frustrierend und anstrengend. Niemand mag es, mit unsauber geschriebenen Code zu arbeiten, wo Fehler fast unvermeidlich sind. Es gibt viele Gründe, warum in Projekten schlechter Code auftreten kann. Vielleicht der Zeitmangel, mangelndes Wissen über Technologie – vielleicht sogar weil man es einfach nicht besser gewusst hat, wie es besser ginge.

Nagut, jetzt wo alles geklärt ist: räum deinen Code auf! Schau, dass du dich an ein paar Good Practices gewöhnst und die Resultate werden sich schneller als du denkst zeigen!