条件付きロジックのクイックビット: 要件とエッジケース

私たちは時間の経過とともに論理条件を読み書きするスキルを開発し、新しい言語機能が新しいソリューションを提供します。しかし、すべてのソリューションが等しいわけではありません。例を簡単に見てみましょう。

設定

複数の場所に存在する可能性のあるプロパティがあり、ネストされたインスタンスを優先したいとします。考えられる解決策をいくつか示します:

// 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;

違いを見つける

これらは機能的にはかなり似ていますが、微妙な違いがあります。ビジネス要件やデータ設計によっては、これらの一部がバグを引き起こす可能性があります。

3 つのオプションを見て、結果が異なるさまざまなシナリオを特定できるかどうかを確認してください。各バージョンではどのような前提を置いていますか?

オペレーター分析

まず、使用されている特定の演算子について考えてみましょう。

• 三項 - 真実 チェックを使用して、どの式が使用されるかを決定します。
• オプションの連鎖 - オブジェクトが nullish の場合は unknown を返しますが、単なる falsy の場合は返しません。
• Nullish Coalescing - 最初の式が Nullish の場合、2 番目の式を使用します。

ヌルくない

ここでは三項演算子が目立ちます。ほとんどの実用的な目的では、オブジェクトについて話しているときと同じように動作します。違いは、物事がうまくいかないときに期待される値に起因します。

未割り当てのオブジェクトは通常、未定義または null です。しかし、プロジェクトで false または「まだオブジェクトではありません!」を使用している場合、3 項で行われた仮定により望ましくない結果が生じる可能性があります。ただし、これはかなりありそうもない特殊なケースです。

意図を理解する

可能性の低い「非オブジェクト」シナリオを無視する場合、オプション A と C は基本的に同一です。

1. config.user が存在する場合は、config.user.setting を取得します。
2. それ以外の場合は、config.setting を取得します。

オプション B は何か違うことをします。

1. config.user.setting が存在する場合は、それを使用します。
2. それ以外の場合は、config.setting を取得します。

違いは小さいですが、要件または技術的な設計上の決定に直接関係します: ユーザーが見つからない場合、config.setting にフォールバックしますか? それとも user.setting が見つからない場合にのみフォールバックしますか?

どちらも有効な可能性ですが、間違った仮定をすると、デフォルトを期待したときに何も得られず、何も期待しなかったときに何かが発生する可能性があります。

結論

ここでは、目標は何かを尋ねる以外に「正しい答え」はありません。より多くのコンテキストが必要です。これらの質問を明確にするよう求めることは、プロジェクト メンバーにとっては衒学的に見えるかもしれませんが、期待に沿った調整が行われていない場合、これらの小さな詳細によって非常に微妙なバグが発生する可能性があります。

このプロジェクト、または会社全体にとって正しい答えがあるかもしれません。 1 つのプロジェクトで複数のオプションを使用することもあります。 1つは価値に焦点を当てること。もう1つは構造に焦点を当てることです。おそらく誰もこれらの違いを考慮しませんでした。おそらくチームは、一致していないのに一致していると思っている。

聞かないと分かりません。

以上が条件付きロジックのクイックビット: 要件とエッジケースの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。