Clean Code: Kurzen+ Performaten Code schreiben (Teil 3)

Clean Code Optimization Coding Lab Steffen Lippke Tutorials und Guides

Clean Code soll nicht nur schön aussehen und gut lesbar sein, sondern dient dazu, die …

  • Performance zu erhöhen
  • Speicherverbrauch zu senken
  • Umfang des Codes zu reduzieren

Der dritte Teil des dreiteiligen Clean-Code-Tutorials soll Dir dabei helfen, wie Du Deinen Code am besten bearbeiten kannst.

Dynamischer Code und Clean Code

Liebe die For-Schleifen!

Warum?

Clean Code ist möglichst dynamisch. Vermeide beim Codieren, die Anzahl der Elemente nicht hart in den Code schreiben, sondern eine Datengrundlage wie z. B. ein (JSON)-Array eine Größe zu nutzen.

Verwende Array-Strukturen – statt Hard-Code!

Dazu iterierst Du über einen Array stückweise weg und gibst Element für Element aus.

💣Coding Horror – So nicht!

Vermeide „hart“ codierte Abschnitte.

document.write("afdaf");
document.write("afdaf");
document.write("afdaf");
document.write("afdaf");
document.write("afdaf");

👌 Clean Code – So sollte Dein Code aussehen

for, foreach oder while sind die Besten!

for(let iterativeCoutner  = 0; iterativeCoutner  < orderList.length; iterativeCoutner ++){
    document.write(orderList[iterativeCoutner]);
}

Clean Code rekursiv oder iterativ

Um Code zu wiederholen, kannst Du iterativ oder rekursiv den Code ausführen. Ich empfehle Dir den iterativen Ansatz zu wählen, da die meisten Programmierer iterativ intuitiv verstehen.

function recursive(i){
    // Anker
    if(i = 0) return 0;
    // Anker 2
    if(i = 1) return 1;
    
    if(i > 1) {
        return this.recursive(i-1);
    }
}

Wenn Dein Code in rekursiver Form die iterative Version in Performance und Kürze deutlich schlägt, solltest Du auf eine beschreibende Benennung achten und rekursiv codieren. Füge zu der Rekursion einen aussagekräftigen Kommentar hinzu, der begründet, warum die Rekursion in diesem Abschnitt besser ist.

Verwende Rekursion nur, wenn dieser DEUTLICH besser ist!

3 Strategien für mehr Qualität

  • Code Review: Wenn Du Deinen Code fertiggestellt hast, kannst Du einem Kollegen Deinen Code vorstellen. Dazu scrollst Du durch den wesentlichsten Code und erklärst, was Du gemacht hast. Dein Kollege sollte Dich auf mögliche Bugs hinweisen, bei Schwachstellen meckern und unsauberen Code kritisieren. Dein Kollege hat eine andere Perspektive auf den Deinen Code.
  • Pair Programming: Der etwas zeitaufwendiger Weg bietet eine hohe Codequalität. Der eine tippt, der andere denkt mit und weist den Tippenden an. Diese Art von Coding vermeidet grobe Bugs und schlechten Spagetti Code.
  • Unit-Tests: Mit Unit-Tests kannst Du überprüfen, ob Dein Programm korrekt läuft. Unit-Tests sind Probedurchläufe mit einfachen Demo-Situationen, der die Ergebnisse der aktuellen Ausführung Deines Codes (IST-Status), mit den zu erwartenden Ergebnisse (SOLL-Status) vergleicht.

Guter Code braucht hartes Feedback von anderen!

Mit Clean Code zu mehr Performance

Wenn Du Deinen Code performanter machen möchtest, brauchst Du eine Clean-Code-Grundlage, um den Code überblicken und verbessern zu können. Verwende dazu Clean Code erster Teil und zweiter Teil. Beim Refactoring fallen Dir (bestimmt) Codeabschnitte auf, die sich in einer dreifachen For-Schleife befinden. Mit einem break; an der richtigen Stelle kannst Du viele unnötige Iterationen sparen.

Lerne alles über die 0-Notation und Laufzeitanalysen

Nicht ÜBER-Optimieren

Beispiel: Im User Interface Design möchtest Du einen Like-Button platzieren.

Mit dynamischem Code könntest Du eine JSON-Datei als Datengrundlage verwenden und diesen mit einer For-Schleife ausgeben. Nachteil am dynamischen Code ist, dass dieser unübersichtlich und sehr kompliziert auf den Betrachter wirkt.

Die beste Optimierung ist keine Optimierung.

Deshalb kannst Du einzelne Komponenten „hart“ coden. Ist in absehbarer Zeit eine Erweiterung mit vielen weiteren Buttons realistisch, dann solltest Du beim dynamischen Code bleiben.

Guter Code ist trocken (DRY)

DRY – Don’t Repeat Yourself – Bevor Du beginnst Code zu schreiben, solltest Du Dir Gedanken, über die Architektur Deines Projekts machen. Trenne stricken die Datenhaltung, Interface und Funktionsschicht (Backend-Code) ab, weil …

  • Die Moden im Interface sich alle 3 Jahre ändern können
  • Datenhaltung von Anfang an immer gleich bleiben soll
  • Kein Programmierer eine App neu builden will, weil nur eine Variable angepasst werden soll

Keine festen Datensätze im Code vermeidet Daten Redundanzen;

  • Verwende eine Programmier-Bibliothek, um keine Zeit zu verlieren.
  • Versuche Muster im Code zu erkennen, um neue Funktionen zu extrahieren.

Wiederhole Dich nicht! (DRY – Don’t Repeat Yourself)

Je generischer Dein Code ist, desto weniger Zeilen Code brauchst Du. Messe Deine Produktivität nicht an Zielen an Code, sondern an funktionierenden und stabilen Funktionen, die Deine Software auszeichnen.

Learnings für diesen Teil

  • Du solltest For-Schleifen lieben!
  • Lerne alles über die 0-Notation und Laufzeitanalysen.
  • Die beste Optimierung ist keine Optimierung.
  • Verwende Array-Strukturen, statt Hard-Code!
  • Rekursion nur verwenden, wenn dieser DEUTLICH besser ist!
  • Guter Code braucht hartes Feedback von anderen!
  • Wiederhole Dich nicht! (DRY – Don’t Repeat Yourself)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Jeden Monat teile ich mit Mitgliedern
4 neue praxisnahe Tutorials (je 1000+ Wörter).


Trage Deine Mail, damit Du
Deine Coding + Hacking Skills erweitern kannst!

Die Webseite nutzt nur technisch notwendige Cookies.