SomeFunction() { ... if (false) { ... } ... }
if（false）ブロックが必要なのはなぜですか？
次のように仮定します。
- これは間違いや物忘れではありません。
- ifおよびfalse-これはまさに条件演算子および論理的な嘘であり、マクロ/行などのトリックではありません。
カットの下のいくつかの回答オプション。 彼らの考えを言いたいと思うそれらはコメントですぐに推測するよう招待されます 。
2つの不適切なオプション
- プログラマーは、行数に対して支払われた作業の外観を作成する必要がありました。
馬鹿げた、面白くないが、それは起こる。 通り抜けました。
- この関数のどこかに、ブロック内にgotoがある場合（false）
私はgotoのイデオロギー的反対者ではありません-時々その使用は正当化されます。 しかし、達成不可能な状態を理解するための移行は、コードの混乱か、それを理解できないほど深い神聖な意味のいずれかです。 通り抜けました。
2つの適切なオプション
1. if（false）ブロックを使用して、コードに一時的にコメントを付けます。
はい、もちろん、 \\ 、 / ** / （またはあなたの言語でコメントを意味するもの）があります。 しかし、これらのことには次の問題があります。
- \\各行に配置する必要があります（はい、一部のIDEにはこのためのホットキーがあります-すべてではありません。これらのホットキーを覚えておく必要があります）。
- / ** /はネストできません。 必要に応じて、すでにそのようなコメントがあるコードをコメントアウトし、不要なアクションをすぐに追加します。その間で選択する必要もあります（すべてにコメントを付け、コメントのタイプを変更し、コメントの内部ブロックを削除します）！
- コメントアウトされたコードは、「コメントアウト-不要」というロジックに従って、別のプログラマーによって簡単に削除できます。 しかし、それは必要かもしれませんが、一時的にコメントアウトされました。 コメントされていないコードのブロックは、おそらくより多くの尊敬を示すでしょう。
- コメント付きのコードはコンパイルされません。 彼が将来必要になる可能性がある場合、環境の変化のために仕事をしない可能性が高くなります。
- コメントアウトされたコードは、リファクタリングツールによってどのようにサポートされているかは不明です。 それを変更する人もいれば、それをどうするか尋ねる人もいれば、単に無視する人もいます。
if（false）ブロックについてコメントするとき、これらの困難のいくつかを免れます。
2. デバッグモードで時々必要な操作を実行する
段階的なデバッグのプロセス（Visual Studioなど）では、プログラム実行の現在のポイントを移動できます。これには、実行しないifブロック内に移動できるという事実も含まれます。
なぜこれが必要なのでしょうか？ さて、ここにいくつかのオプションがあります：
- このブロックでは、非常に重いログを作成できます（たとえば、メモリ全体のダンプなど）。 通常モード（およびデバッグ構成でも）では、これは必要ありませんが、デバッグ中に、難しい場所が必要になる場合があります。 このダンプをif（false）でラップし、適切なタイミングでその内部にジャンプしてから戻ります。
- 同じデバッグの過程で、テストのためにオブジェクトを何らかの参照状態に転送する必要があります。 リリースでもデバッグでも、これは何を必要としますか-デバッグのためだけに。 さらに、おそらく将来的に-問題がある場合。 if（false）でオブジェクトの初期化をラップします-これにより、プログラム内にコードが存在することが保証され、適切なタイミングで実行を内側にスローします。