**Dies ist eine alte Version des Dokuments!**
Tipps zur (objektorientierten) Programmierung
Defensive Programmierung
Bugfixing
Codeoptimierungen
(siehe Skript Datenstrukturen und Algorithmen)
Constant Propagation: wo es geht Konstanten anstatt von Variablen verwenden
Common Subexpression Elimination: einmalige Berechnung gleicher Ausdrücke
Operator Strength Reducing: Bitshifts beim Rechnen mit Zweierpotenzen verwenden
Copy Propagation: keine überflüssigen oder doppelten Berechnungen
Loop Strength Reduction: Vermeiden überflüssiger Schleifendurchläufe durch Verwenden des passenden Inkrements (z.B. i += 10
anstatt i++
)
Invariant Code Motion: Entfernen invarianter Ausdrücke (Berechnungen mit immer gleichem Ergebnis in der Schleife oder dem Schleifenkopf) aus Schleifen
Loop Jamming: Zusammenfassen mehrerer Schleifen zu einer
Vermeidung unnötiger Indexzugriffe auf Arrays (da interne Multiplikationen zur Ermittlung des Speicherplatzes nötig)
keine überflüssigen Funktionsaufrufe (Operatoren sind meist schneller)
Designprinzipien
nach {[quellen:Bleek2008|S. 87]}
Don't Repeat Yourself (DRY): Funktionen werden nur einmal implementiert und nicht mehrmals (womöglich gar durch Copy-and-Paste) → Modularisierung, bessere Wartbarkeit
Speaking Code Principle (SCP): der Code muss auch ohne Kommentare verständlich sein → bessere Wartbarkeit, einfachere Einarbeitung anderer Entwickler
Separation of Concerns (SoC): jedes Modul hat genau eine Aufgabe → Modularisierung, bessere Wartbarkeit, DRY
Tell, don't ask (TDA): Klassen sollten nicht nach Werten gefragt, sondern aufgefordert werden, eine Funktion zu liefern (z.B. nicht MwSt-Satz abfragen, sondern auffordern, Mehrwertsteuer zu berechnen) → verhindert ausufernde Abhängigkeiten zu anderen Klassen, evtl. jedoch Konflikt zu SoC
ToDo
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
Law of Demeter
Test-first