0

私は次のことを指しています。

void setup_gui()
{
    if (some_condition)
        some_button.disable();

    ...
}

void some_button_click()
{
    // Is this a good practice?
    if (some_condition)
        return;

   ...
}

そのチェックを追加すると、プログラムが操作を実行しないようになりますが、バグを隠していると見なすこともできます (some_button_click() はまったく実行されていないはずです)。

それで、あなたはそれについてどう思いますか？それは安全なコーディング方法ですか、それともバグを隠していますか?

4

4 に答える 4

2

防御的なプログラミングは、防御的な運転と同じくらい合理的です。

これは、個別の懸念事項の観点から考えると役立つ場合があります。1つの懸念はプレゼンテーションです。もう 1 つは一連のビジネス ルールです。両方の場所で同じチェックを行うのが合理的です。

ユーザーと通信するためにプレゼンテーション層でチェックを行いたい。

プレゼンテーション レイヤーの下でチェックを行うこともできます。

  • プレゼンテーション層での現在および将来の間違いを防ぐため。
  • プレゼンテーション層の下のコードが別の場所で再利用される場合。
  • 【mvdsさんのコメントより】 コントロールを有効または無効にした後、状態が変わる可能性がある場合に備えて。

編集:以下の David Heffernan の DRY の懸念は、条件を 1 回だけ定義し、別の場所にアクセスすることで簡単に対処できます。

void setup_gui()
{
    some_button.setEnabled( context.isThisActionAvailable() );

    ...
}

void some_button_click()
{
    if ( context.isThisActionAvailable() )
        return;

   ...
}
于 2011-01-05T14:55:30.847 に答える
1

私はこのベルトとブレースのアプローチを取りません。問題は、some_condition を二重に使用して DRY 原則に違反していることです。これをある場所で変更し、別の場所で変更するのは簡単です。

もちろん、この作成された例では some_condition は非常に単純ですが、実際にはもっと複雑になることがよくあります。

アクションをブロックするように要求したときに GUI フレームワークがアクションをブロックすることを信頼できない場合は、フレームワークを修正する必要があります。

于 2011-01-05T15:09:15.113 に答える
0

サイレントリターンはsome_button_click()潜在的にバグを隠します。私はチェックをまったく行わないか、大声で激しくクラッシュします。

于 2011-01-05T15:13:44.147 に答える
0

これは安全なコーディングと見なすことができ、バグを隠していると見なすこともできます。これは、おそらくプログラム ロジックを再評価する必要があるときです。コードの冗長性は、可能であれば避けるのが常に最善です。プログラムの実際のロジックが適切に意図したとおりに動作することを確認することで、2 回チェックする必要がないようにプログラムを構成できるとよいでしょう。

確かに、急いでいる場合、これは簡単な修正であり、機能しますが、プログラムの他の場所で設計やロジックの悪臭がします。

于 2011-01-05T15:03:05.903 に答える