Bedingte Logik-Schnellbits: Anforderungen und Randfälle

Wir entwickeln im Laufe der Zeit Fähigkeiten zum Lesen und Schreiben logischer Bedingungen, und neue Sprachfunktionen können uns neue Lösungen bieten. Aber nicht alle Lösungen sind gleich. Werfen wir einen kurzen Blick auf ein Beispiel.

Aufstellen

Angenommen, wir haben eine Eigenschaft, die möglicherweise an mehreren Stellen vorhanden ist, und wir möchten der verschachtelten Instanz Priorität einräumen. Hier sind einige mögliche Lösungen:

// Option A: Ternary
const setting = config.user ? config.user.setting : config.setting;

// Option B: Optional Chaining and Nullish Coalescing
const setting = config.user?.setting ?? config.setting;

// Option C: Destructuring and Nullish Coalescing
const { setting } = config.user ?? config;

Erkennen Sie die Unterschiede

Diese sehen in der Funktionalität ziemlich ähnlich aus, es gibt jedoch subtile Unterschiede. Abhängig von unseren Geschäftsanforderungen oder unserem Datendesign können einige davon Fehler verursachen.

Schauen Sie sich die drei Optionen an und prüfen Sie, ob Sie die verschiedenen Szenarien identifizieren können, in denen das Ergebnis unterschiedlich sein wird. Welche Annahmen treffen wir bei jeder Version?

Operatoranalyse

Berücksichtigen Sie zunächst die spezifischen Operatoren, die im Spiel sind.

• Ternär – verwendet eine Wahrheitsprüfung, um zu entscheiden, welcher Ausdruck verwendet wird.
• Optionale Verkettung – gibt undefiniert zurück, wenn das Objekt null ist, aber nicht, wenn es nur falsch ist.
• Nullish Coalescing – verwendet den zweiten Ausdruck, wenn der erste nullish ist.

Nicht Nullish

Hier sticht der ternäre Operator hervor. Für die meisten praktischen Zwecke verhält es sich genauso, wenn wir über Objekte sprechen. Die Unterschiede hängen davon ab, was wir von den Werten erwarten, wenn die Dinge nicht funktionieren.

Ein nicht zugewiesenes Objekt ist normalerweise undefiniert oder null. Wenn unser Projekt jedoch false oder „Noch kein Objekt!“ verwendet, könnte die mit dem Ternär getroffene Annahme zu unerwünschten Ergebnissen führen. Es ist jedoch ein ziemlich unwahrscheinlicher Randfall.

Absicht verstehen

Wenn wir das unwahrscheinliche „Nicht-Objekt“-Szenario ignorieren, sind Optionen A und C im Grunde identisch.

1. Wenn config.user vorhanden ist, rufen Sie config.user.setting ab.
2. Andernfalls rufen Sie config.setting ab.

Option B macht etwas anderes.

1. Wenn config.user.setting vorhanden ist, verwenden Sie es.
2. Andernfalls rufen Sie config.setting ab.

Der Unterschied ist gering, spricht aber direkt für eine Anforderungs- oder technische Designentscheidung: Fallen wir auf die Konfigurationseinstellung zurück, wenn der Benutzer fehlt, oder nur, wenn die Benutzereinstellung fehlt?

Beide sind gültige Möglichkeiten, aber wenn wir die falsche Annahme treffen, haben wir am Ende möglicherweise nichts, wenn wir den Standardwert erwarten, oder etwas, wenn wir nichts erwarten.

Abschluss

Hier gibt es keine „richtige Antwort“, außer zu fragen, was das Ziel ist. Wir brauchen mehr Kontext. Die Bitte um Klärung dieser Fragen mag für Projektmitglieder pedantisch erscheinen, aber diese kleinen Details können zu sehr subtilen Fehlern führen, wenn wir uns nicht an den Erwartungen orientieren.

Vielleicht gibt es für dieses Projekt oder für ein ganzes Unternehmen die richtige Antwort. Möglicherweise nutzen wir sogar mehrere Optionen in einem einzigen Projekt. einer, der sich auf den Wert konzentriert; ein anderer, um sich auf die Struktur zu konzentrieren. Vielleicht hat niemand diese Unterschiede berücksichtigt. Vielleicht denkt das Team, dass sie sich einig sind, obwohl dies nicht der Fall ist.

Sie werden es nicht wissen, wenn Sie nicht fragen.

Das obige ist der detaillierte Inhalt vonBedingte Logik-Schnellbits: Anforderungen und Randfälle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!