Regel
Erkennen widersprüchlich oder unmögliche Logik
Code , der überprüft Bedingungen nach sie
bereits verstoßen verletzt wurden, oder geht davon aus, dass , dass
, dass unmöglich unmöglich angesichts die Kontrolle .
Unterstützte Sprachen: 45+Einleitung
Widersprüchliche Logik tritt auf, wenn Code Bedingungen prüft, die aufgrund eines früheren Kontrollflusses bereits als wahr oder falsch bekannt sind. Dies geschieht nach einem Refactoring, wenn die Validierung neu angeordnet wird, oder wenn Entwickelnde defensive Prüfungen hinzufügen, ohne zu verstehen, welche Garantien bereits bestehen. Eine Funktion, die prüft if (user !== null) nach dem Aufruf user.email weist widersprüchliche Logik auf, der Null-Check kommt zu spät. Diese logischen Unmöglichkeiten weisen auf tiefere Probleme bei der Code-Organisation oder ein fehlendes Verständnis dafür hin, was jeder Code-Pfad garantiert.
Warum es wichtig ist
Sicherheitsimplikationen: Falsche Validierung erzeugt eine gefährliche Illusion von Sicherheit. Wenn Sicherheitsprüfungen erst nach der Verwendung der Daten erfolgen, können Angreifer das Zeitfenster vor der Validierung ausnutzen. Code, der Benutzerberechtigungen nach der Ausführung privilegierter Operationen validiert, bietet keinen tatsächlichen Schutz, sondern nur irreführende Kommentare zur Sicherheit.
Code-Wartbarkeit: Widersprüchliche Logik deutet darauf hin, dass der Code nicht dem mentalen Modell der Entwickelnden entspricht. Jemand dachte, eine Bedingung müsse überprüft werden, platzierte sie aber falsch, oder der Code wurde refaktorisiert, ohne die zugehörigen Prüfungen zu aktualisieren. Zukünftige Wartende können sich nicht darauf verlassen, dass Validierungen dort existieren, wo sie benötigt werden, was sie zwingt, ganze Funktionen zu durchsuchen, um die tatsächlichen Garantien zu verstehen.
Fehlerindikatoren: Unmögliche Bedingungen existieren selten isoliert. Sie weisen auf tiefere Probleme hin, wie fehlende Fehlerbehandlung, falsche Annahmen über Funktionsverträge oder fehlgeschlagenes Refactoring. Eine Prüfung, die niemals ausgeführt werden kann, bedeutet oft, dass an anderer Stelle eine andere Prüfung fehlt, die diesen Zustand hätte verhindern sollen.
Code-Beispiele
❌ Nicht konform:
function processOrder(order) {
if (!order) {
return { error: 'Order required' };
}
const total = order.items.reduce(
(sum, item) => sum + item.price,
0
);
if (order.items && order.items.length > 0) {
applyDiscount(order);
}
if (total < 0) {
throw new Error('Invalid total');
}
return { total, status: 'processed' };
}
Warum es falsch ist: Der Code ruft auf order.items.reduce() der abstürzt, wenn Elemente ist null oder undefined, und prüft dann, ob items danach existieren. Die total < 0 Die Prüfung ist auch widersprüchlich, da die Reduktion beim Summieren von Preisen immer nicht-negative Werte zurückgibt.
✅ Konform:
function processOrder(order) {
if (!order || !order.items || order.items.length === 0) {
return { error: 'Valid order with items required' };
}
const hasInvalidPrice = order.items.some(
item => typeof item.price !== 'number' || item.price < 0
);
if (hasInvalidPrice) {
throw new Error('Invalid item prices');
}
const total = order.items.reduce(
(sum, item) => sum + item.price,
0
);
if (order.items.length >= 5) {
applyBulkDiscount(order);
}
return { total, status: 'processed' };
}
Warum das wichtig ist: Alle Validierungen erfolgen vor der Verwendung der Daten, Prüfungen geschehen in logischer Reihenfolge und Bedingungen spiegeln die tatsächlichen Anforderungen wider. Die Funktion validiert Eingaben im Voraus und verarbeitet dann gültige Daten ohne redundante oder widersprüchliche Prüfungen.
Fazit
Platzieren Sie die Validierung, bevor Sie Daten verwenden, nicht danach. Überprüfen Sie Bedingungen, die defensiv erscheinen, aber erst nach dem Zugriff oder der Änderung der Daten auftreten. Beim Refactoring aktualisieren oder entfernen Sie zugehörige Validierungen, um die logische Konsistenz innerhalb der gesamten Funktion zu gewährleisten.
.avif)
