プログラミングの原則：割り当てと条件との関係

Question

私はいくつかの研究を行ったが、私が探していた答えを見つけることができなかったので、私はこの問題をここで取り上げると思った。私はそれは例を使用して、それを証明するため、次のコードスニペットを検討することをお勧めだと思う：

int delta = 0; 
if (some_condition) 
    delta = 42; 

x1 = regular_value1 + delta; 
x2 = regular_value2 + delta; 
// ... 
// where delta is used a lot of times 
// basically - if (some_condition == true) => add delta to all variables 
// if FALSE - add 0 (thus, effectively not changing anything) 

例えば

int delta = 42; 

if (some_condition) 
{ 
    x1 = regular_value1 + delta; 
    x2 = regular_value2 + delta; 
    // ... 
} 
else 
{ 
    x1 = regular_value1; 
    x2 = regular_value2; 
    // ... 
} 

対を、非常に単純な実世界のシナリオは次のようになりますのは、言ってみましょう私は左にイメージを含む可能性がありますWindowsフォームを作成しています。画像がない場合は、残りのすべてのフォームコントロールを左側に作成し、画像がある場合は、他のすべてのコントロールを画像の右側に移動します（すべてのコントロールのX位置にデルタを追加します）。

私はC＃XNAゲームをプログラミングしています（したがって、パフォーマンスはいくらか関連性がありますが、OOPの原則は決して省略してはいけません）ので、私の質問は「some_condition」がTRUE時間の50％？同様に、どのコードブロックの保守や読み込みが容易ですか？

私はこれが大きな問題ではないことを認識していますが、私は可能な限りベストコードを書くという習慣に慣れようとしています。どんな入力や個人的な経験さえも評価されます。

ありがとうございました。

Answer 1

後者はやや速いかもしれませんし、両方が同じものに最適化されているかもしれません。それは重要ではありません。あなたが問題になることがわかったら、いつでも後で変更することができます（この事例は確かにありません - これは一般的なアドバイスです）。しかし、私は少なくとも、読んで維持することがより容易であることを発見しました。 regular_value1またはregular_value2を変更する場合は、2つではなく1か所で変更するだけです。それのために行く。

Answer 2

これはちょっとした主観的な質問ですが、可読性に影響を与えるもの（および保守性も重要なもの）の1つは、コードの繰り返し数です。この場合、最初のオプションでは、保守と読み込みのコードが少なくて済み（冗長性が低くなります）、私の推奨する方法になります。

Answer 3

これは確かに単純なケースです。理解しやすいものを使うことをお勧めします。これはあなたがここに示した以上のプログラムに基づいていなければならない決定です。

しかし、第2の解決策は、特に「デルタ」が定数に変わった場合に、より速くなりがちです。 "some_condition"がfalseの場合、追加を行う必要はなく、optmizerは実際の割り当てを高速化する何らかの方法を考え出すことができるかもしれません。メンテナンス性を損なうことがなければ、できる限り速いコードを書くのが最善だと思います。これよりもパフォーマンスの差がはるかに大きいものであっても、後でスピードアップする方法を探すことは決して現実的ではありません。あなたはパフォーマンスのためのコードを作成して、それを忘れるかもしれません。時間をかけてこれを保つと、あなたのコードは無料で速く実行されます。

いつかプロファイリングすると、このコードがプログラムの中で最も遅いポイントになることがあります。しかし、ほとんどの場合、あなたと他者は、コードが特定の速度で実行され、それに応じて使用されるという事実を受け入れます。ユーザーを迷惑にすることなく、スピードアップして新しい場所で使用できること（キーストロークの間など）は決して考えられません。

ここでのパフォーマンスの違いは軽微であり、おそらくコードはスピードクリティカルな状況では決して使用されませんが、スピードのコーディングは良い考えです。一度あなたが習慣に入ると、実際には時間がかかりません。あなたのコードは、すでに調整されているので、あなたのコードが微調整できれば何をすることができるかを知っています。

（これは私の経験では、コードと読みやすいコードが同じものです。人間がコードを簡単に理解できれば、オプティマイザが可能になり、最近はオプティマイザが王様です。私はすべてが速くされているコードに依存知っない限り選択することが、私は明瞭ではなく、スピードのために行くのです。それから私は償うために狂ったように文書化する。）

Answer 4

@minitechで指摘したように、第2のアプローチは、することができますとなります確かに保守性の問題を引き起こします（は、を指摘しています：アプリケーションのライフサイクルはどれくらいですか？あなたが書いているコードは他の人が再利用したり、消費していますか？あなたがすでにこれらの要素を考慮していることを考えれば、あなたのアプリケーションが準拠すべきパフォーマンス数値をいくつか決めて設定することをお勧めします。

パフォーマンス要件が明確に設定されたら、どのアプローチを従うべきかを決めることができます。 OOPの原則と読みやすさはすべてのプログラマーにとって夢ですが、アプリケーションを顧客に出荷すると、どのアプローチに従っても問題ありません。アプリケーションが期待通りに動作することが重要です（両方の観点から機能とパフォーマンス）。

「ベスト」と「ベスト」コードがもたらす可能性のある実際のパフォーマンスへの影響の関係について、ステークホルダーとの関係を把握する必要があります。