• entsprechende Datentypen für nicht-negative Zahlen verwenden (z.B. unsigned int) um aufwändige Prüfungen des Wertebereichs zu vermeiden

• für jeden gefundenen Bug wird eine entsprechende Assertion eingefügt, damit ein erneuter Verstoß gegen die Rahmenbedingungen sofort auffällt

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

• Single Responsibility Principle
• Open Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
• Law of Demeter
• Test-first