Clean Code Prinzipien

Clean Code Prinzipien in JavaScript und TypeScript anwenden

Wir als Berater bei der QUANTO Solutions stehen bei unseren Kunden regelmäßig vor der Aufgabe, bereits existierende Projekte, Konzepte, Strukturen und bestehenden Quellcode von anderen Entwicklern zu übernehmen und auf dieser Basis aufzubauen. Zudem gehört die Übergabe eines Projekts oder einer Applikation nach erfolgreicher Entwicklung zu unseren Aufgaben. Um diese Übergänge so unkompliziert wie möglich zu gestalten und möglichst effizient im Team zu arbeiten, hilft es die Clean Code Prinzipien einzuhalten.

In diesem Blogbeitrag werden einfach umzusetzende Ansätze beschrieben, die dabei helfen, unseren Quellcode nach den Clean Code Prinzipien aufzubauen. Die Guidelines können auf die Programmierung in den verschiedensten Sprachen angewandt werden, wobei hier die positiven Effekte auf die Entwicklung mit JavaScript und TypeScript näher beleuchtet werden sollen.

Was versteht man unter „Clean Code“

Der Begriff „Clean Code“ geht auf den Autor Robert C. Martin und dessen gleichnamiges Buch zurück. Martin beschreibt darin, dass es bei der Entwicklung von „sauberem“ Code in erster Linie darum geht, sich Gedanken um die Gestaltung und Lesbarkeit von Quellcode zu machen. Folgende Eigenschaften werden mit Clean Code assoziiert:

  • Elegant
  • Leicht
  • Direkt
  • Effektiv

Ein „sauberer“ Quellcode ist daher auch für außenstehende Entwickler lesbar, wartbar und kann mit weniger Aufwand erweitert werden.

Clean Code Decisions

Wie schreibt man Clean(eren) Code?

Clean Code Prinzipien

DIPDependency Inversion PrincipleHöhere Ebenen sind nicht von niedrigen Ebenen abgängig.
DRYDon’t Repeat YourselfWiederholungen vermeiden.
ISPInterface Segregation PrincipleSchnittstellen sollen nur Elemente enthalten, wie von den implementierenden Klassen benötigt werden.
KISSKeep it Simple and StupidStets die einfachste Lösung für die Anforderung suchen und implementieren.
LSPLiskov Substitution PrincipleAbgeleitete Subklassen dürfen die Funktionen ihrer Superklassen lediglich erweitern, nicht verändern.
OCPOpen Closed PrincipleModule, Klassen, Methoden sollten offen für Erweiterungen aber geschlossen für Änderungen sein.
SoCSeparation of ConcernsVerschiedene Aufgaben werden in eigenen Einheiten umgesetzt.
SRPSingle Responsibility PrincipleEine Funktion bzw. Klasse erfüllt nur eine Aufgabe.
TDATell Don’t AskEin Objekt oder eine Funktion sollte nicht nach Daten fragen, sondern benötigte Daten werden übergeben.
YAGNIYou Ain’t Gonna Need ItFunktionalität wird nur implementiert, wenn sie benötigt wird.

In den folgenden Absätzen werden praktische Ansätze vorgestellt, die dabei helfen, die Clean Code Prinzipien umzusetzen.

Namenskonventionen

Einwichtiger Baustein von leserlichem Quellcode und damit Clean Code, der oft etwas zu kurz kommt, ist die überlegte Benennung von Variablen und Funktionen. Je besser anhand des Namens erkannt werden kann, was eine Funktion macht oder wofür eine Variable steht, desto leichterkann der Code im Nachhinein oder von einem Außenstehenden gelesen und verstanden werden. Folgende Namenskonventionen können dabei helfen, den richtigen Namen zu bestimmen:

  • Der Name einer Variablen/Funktion gibt immer deren Kontext an
  • Es werden stets aussprechbare Namen verwendet (keine Abkürzungen, usw.)
  • Die Sprache sowie die Schreibweise der Namen sollte im gesamten Projekt konsequent angewandt werden (Aufgrund der Lesbarkeit, ist eine Schreibweise in CamelCase zu empfehlen)
curPositioncurrentPosition
sPositionstartPositon
start_positionstartPosition
dday

Bedingungen

Beim Schreiben von Quellcode werden häufig Bedingungenbenötigt, welche den Code es schnell Komplex und kompliziert machen können. Um dennoch dem Clean Code Prinzip KISS (Keep it Simple and Stupid) zu folgen, können folgende Grundregeln helfen, tiefe Verschachtelungen und Abhängigkeiten zu vermeiden. Und den Quellcode so möglichst einfach zu halten.

Gibt es Bedingungen, die dafür sorgen, dass keinerlei Logik durchlaufen werden muss, ist es besser diese direkt am Anfang der Funktion zu überprüfen. Innerhalb einer Funktion sollte maximal zweifach vertieft werden. Bei Bedingungen, die aus mehreren Konditionen bestehen ist es ratsam, diese in einer separaten Funktion zu Prüfen und den Booleschen Wert zurückzugeben.

function: isSkillAvaileable(searchSkill) {
	if (!skillTitle) {
return false;
}
const skillsOfDeveloper = [“JS”, “TS”];
return skillsOfDeveloper.includes(developerSkill => developerSkill === searchSkill);
}
	

Innerhalb von Bedingungen werden häufig Strings miteinander verglichen, dabei werden häufig sogenannte „magische Strings“ verwendet. Mit „magischen Stings“ sind Zeichenketten (aber auch Nummern) zu verstehen, mit denen im Code ein Effekt erzielt werden kann, zum Beispiel wird eine If-Bedingung erfüllt. Bei direkter Anwendung solcher Strings ist oft nicht klar, welcher semantische Wert gemeint ist. Zudem müssen bei Änderungen dieser Zeichenketten Duplikate an verschiedenen Stellen im Quellcode angepasst werden. Der Code wird unleserlich und die Wartung erschwert, eine einfache Lösung dieser Problematik und eine weitere Guideline zur Einhaltung der Clean Code Prinzipien, stellen zentral Definierte Konstanten dar, deren Namen den semantischen Wert festlegen.

Um einen Quellcode automatisiert auf unbenannte Strings, nicht verwendete Variablen oder Anzahl der Übergabeparametern in Funktionen zu überprüfen, kann das Linting-Tool ESLint (unterstützt ECMAScript 6 und ist damit für JS und TS Applikationen geeignet) verwendet werden. Das Tool identifiziert auf Basis von Regeln, welche vom Autor des Codes festgelegt werden können, welche Stellen im Code hervorgehoben bzw. als kritisch markiert werden.

Funktionen

Funktionen sollten kurz und lesbar gehalten werden, dabei spielt das Clean Code Prinzip SRP (Single-Responsibility-Prinzip) eine wichtige Rolle. Jede Funktion erledigt immer nur eine Aufgabe und ist damit leicht zu testen und wiederverwendbar.

Das hilft dem Entwickler dabei, dem nächsten Clean Code Prinzip – DRY (Don’t Repeat Yourself), gerecht zu werden. Sind alle Funktionen nur für eine Aufgabe bestimmt, können sie ohne Seiteneffekte an verschiedenen Stellen aufgerufen werden und Wiederholungen im Code werden nicht benötigt. Um solche Wiederholungen im Code zu markieren kann auch ein JSCPD Tool herangezogen werden.

Allerdings ist es erfahrungsgemäß für den Entwickler nicht immer leicht zu erkennen, wann eine Funktion zu Komplex ist. Es gibt jedoch Indizien, die darauf schließen lassen, dass eine Funktion zu viele Aufgaben erledigt:

  • Einer Funktion sollten maximal 2-3 Parameter übergeben werden:

Semantisch zusammengehörige Felder sollten in einem Objekt zusammengefasst werden, sind es dennoch mehr als 3 Parameter ist es wahrscheinlich, dass Funktion aufgeteilt werden sollte

function: createEmployeeEntry({firstName, name, age}) {
	//Do Something
}

createEmployeeEntry ({“Marta”, “Muster”, 29});
  • Es werden boolesche Werte (Flags) übergeben:

In diesem Fall unternimmt die Funktion eine Fallunterscheidung, was mindestens 2 Handlungssträngen entspricht und ihr kann damit keine eindeutige Verantwortlichkeit mehr zugesprochen werden

  • Bedingungen oder Schleifen sind zu verschachtelt. Es sollte, wie bereits im Kapitel Bedingungen erwähnt, über nicht mehr als zwei Ebenen vertieft werden.

Fazit

Es gibt noch viele weitere Ansätze, wie die Clean Code Prinzipien in der Praxis umgesetzt werden können, doch jeder Entwickler legt dabei auf andere Punkte Wert. Außerdem es gibt immer wieder neue Ansätze, die das Schreiben von Quellcode verbessern können. Dabei kann man sich schnell in vielen Details verlieren. Und ist es für den Entwickler mit einem größeren Aufwand verbunden, jede Funktion bis hin zur einzelnen Variablen zu überprüfen und zu hinterfragen.

Und doch können bereits kleinere Gewohnheiten einen großen Unterschied machen. Je lesbarer, testbarer und damit wartbarer Quellcode entwickelt wird, desto besser wird dessen Qualität und das kommt vor allem unseren Kunden und den Endusern zugute. Aufwände für Refactoring und Erweiterungen werden deutlich kleiner und die Funktionalität der Applikation an sich steht im Fokus.

Weiterführende Links und Videos:

Autor: Vanessa Deutsch

Kontakt: https://quanto-solutions.de/#kontakt

Tags

Bewirb Dich noch heute: Das Masterclass Traineeprogramm SAP Consultant startet im Januar 2023

Cloud Engineer & SAP Developer - bereits ausgebucht

X