Dieses kurze Refactoring-Tutorial zeigt, wie du Guard Clauses für deine if-Anweisungen schreibst, statt verschachtelte if-else-Logik zu bauen. Das ist einer der schnellsten Wege zu sauberem, gut lesbarem Code. Das Beispiel ist in JavaScript geschrieben, derselbe Stil gilt aber für jede Sprache – PHP, Java und den Rest.
Was ist eine Guard Clause?
Das Guard-Clause-Pattern ist schlicht eine Technik, um früh in einer Methode zu prüfen, etwa in einem Konstruktor. Wenn eine Methode (oder eine Objektinstanz) bestimmte Werte braucht, um korrekt zu arbeiten, und die Anwendung diesen Code nie mit ungültigen Eingaben aufrufen sollte, wirft die Guard Clause eine Exception, sobald ein Wert eine der aufeinanderfolgenden Bedingungen nicht erfüllt. Unter anderem ersparst du dir damit ineinander verschachtelte if-else-Blöcke im Ablauf einer Methode.
JavaScript-Beispiel für die Guard-Clause-Technik
Stell dir vor, du sollst eine Methode schreiben, die ein Datum je nach Wert formatiert: Es kann ein Timestamp sein, ein Date-Objekt oder eine Zeichenkette, alles andere ist ein Fehler. Verlockend ist dann eine Kette aus verschachtelten if / else if / else.
Ohne Guard Clauses
function getDate(date) {
let result;
if (!isEmpty(date)) {
if (isTimestamp(date)) {
result = formatWithTimestamp(date);
else if (isDateObject(date))
result = formatWithObject(date);
else if (isString(date))
result = formatWithString(date);
else
throw new DateFormatException(date);
}
return result;
}
return emptyDateError();
}
Mit Guard Clauses
function formatDate(date) {
if (isEmpty($date)) return emptyDateError();
if (isTimestamp(date)) return formatWithTimestamp(date);
if (isDateObject(date)) return formatWithObject(date);
if (isString(date)) return formatWithString(date);
throw new DateFormatException(date);
}Der Unterschied fällt sofort auf: Mit Guard Clauses liest sich der Code deutlich leichter und bleibt wartbar, für dich wie für deine Kollegen.
Fazit
Guard Clauses und Validierungsprüfungen validieren beide Eingaben. Der Unterschied liegt darin, ob die ungültige Eingabe erwartet wird und zur Anwendung gehört oder ob sie wirklich unerwartet ist. Nimm Exceptions nur für die unerwarteten Fälle und gewöhnliche Validierungslogik für die Probleme, die du bei eingehenden Daten ohnehin kennst.
