For-ifアンチパターン

for-ifアンチパターンについてこのブログ投稿を読んでいましたが、なぜそれがアンチパターンであるのか理解できません。

foreach (string filename in Directory.GetFiles("."))
{
    if (filename.Equals("desktop.ini", StringComparison.OrdinalIgnoreCase))
    {
        return new StreamReader(filename);
    }
}

質問1：

それが理由であるreturn new StreamReader(filename);内部for loop？または、forこの場合ループが必要ないという事実ですか？

ブログの作者が指摘したように、これのクレイジーでないバージョンは次のとおりです：

if (File.Exists("desktop.ini"))
{
    return new StreamReader("desktop.ini");
} 

の作成前にファイルが削除されるとStreamReader、を取得するため、どちらも競合状態になりますFile­Not­Found­Exception。

質問2：

2番目の例を修正するには、ifステートメントなしで書き直し、代わりにをStreamReadertry-catchブロックで囲み、それがスローされるFile­Not­Found­Exception場合は、それにcatch応じてブロックで処理しますか？

これは次の形式をとるため、アンチパターンです。

loop over a set of values
   if current value meets a condition
       do something with value
   end
end

と置き換えることができます

do something with value

この典型的な例は次のようなコードです：

for (var i=0; i < 5; i++)
{
    switch (i)
        case 1:
            doSomethingWith(1);
            break;
        case 2:
            doSomethingWith(2);
            break;
        case 3:
            doSomethingWith(4);
            break;
        case 4:
            doSomethingWith(4);
            break;
    }
}

以下がうまくいくとき：

doSomethingWith(1);
doSomethingWith(2);
doSomethingWith(3);
doSomethingWith(4);

自分がループとiforを実行していることに気付いた場合switchは、停止して、何をしているのかを考えてください。あなたは物事を複雑にしすぎていませんか？ループ全体とテストを単純な "ただやる"行で置き換えることができますか？ただし、そのループを実行する必要がある場合もあります（たとえば、複数のアイテムが1つの条件に一致する場合があります）。その場合、パターンは適切です。

それがアンチパターンである理由です：それは「ループとテスト」パターンを受け取り、それを悪用します。

2番目の質問について：はい。コードがテスト中のアイテムの状態を変更する可能性のあるデバイス全体の唯一のスレッドではない状況では、「try do」パターンは「test then do」パターンよりも堅牢です。

このコードの問題：

if (File.Exists("desktop.ini"))
{
    return new StreamReader("desktop.ini");
}

間の時間であるということFile.ExistsとStreamReader、そのファイルを開こうとすると、別のスレッドまたはプロセスがファイルを削除することができます。したがって、例外が発生します。したがって、その例外は次のような方法で保護する必要があります。

try
{
    return new StreamReader("desktop.ini");
}
catch (File­Not­Found­Exception)
{
    return null; // or whatever
}

@Flaterは良い点を提起しますか？これ自体はアンチパターンですか？制御フローとして例外を使用していますか？

コードが次のようなものを読んだ場合：

try
{
    if (!File.Exists("desktop.ini")
    {
        throw new IniFileMissingException();
        return new StreamReader("desktop.ini");
    }
}
catch (IniFileMissingException)
{
    return null;
}

それから私は確かに例外を栄光のgotoとして使用していて、それは確かにアンチパターンです。ただし、この場合は、新しいストリームを作成するという望ましくない動作に対処しているだけなので、これはそのアンチパターンの例ではありません。しかし、それはそのアンチパターンを回避する例です。

もちろん、私たちが本当に望んでいるのは、ストリームを作成するよりエレガントな方法です。何かのようなもの：

return TryCreateStream("desktop.ini", out var stream) ? stream : null;

またtry catch、このコードを頻繁に使用している場合は、このようなユーティリティメソッドでコードをラップすることをお勧めします。

質問1：（このforループはアンチパターンですか？）

はい。クエリ可能なサブシステムに格納されているアイテムを独自に検索する必要がないためです。

要約すると、データベースと同様に、ファイルシステムはクエリに応答できます。クエリ可能なサブシステムとやり取りするとき、サブシステムの外部でマッチングを実行するためにそのようなサブシステムにコンテンツを列挙させるか、サブシステムのネイティブクエリ機能を使用するかについて、基本的な選択があります。

ファイルシステム内のディレクトリ内のファイルではなく、データベース内のレコードを検索しているとしましょう。むしろ見たいですか

SELECT * FROM SomeTable;

次に、返されたカーソルをループして（たとえばC＃で）ID = 100を探しますか、それともクエリ可能なサブシステムに、探しているものを正確に見つけるためにできることを実行させますか？

SELECT * FROM SomeTable WHERE ID = 100;

私たちのほとんどは、サブシステムに目的の正確なクエリを実行させることを正しく選択するだろうと考えるべきです。代替案には、サブシステムとの潜在的な多数のラウンドトリップ、非効率的な等価性テスト、およびデータベースとファイルシステムの両方が提供するインデックスやその他の検索アクセラレータの使用を忘れることが含まれます。

質問2：2番目の例を修正するには、ifステートメントなしで書き直して、代わりにStreamReaderをtry-catchブロックで囲み、FileNotFoundExceptionをスローする場合は、それに応じてcatchブロックで処理しますか？

はい、これはその特定のAPIが機能する方法です。これはライブラリ関数であるため、実際には私たちの選択ではありません。呼び出し前のifチェックでは追加の値は提供されません。（1）FileNotFound以外の他のエラーが発生する可能性があるため、（2）競合状態であるため、とにかくtry / catchを使用する必要があります。

質問1：

これは、新しいStreamReader（filename）を返すためですか。forループ内？または、この場合はforループが必要ないという事実ですか？

streamreaderはそれとは何の関係もありません。との間の明確な意図の対立により、アンチパターンが出現foreachしifます。

の目的は何foreachですか？

あなたの答えは次のようなものになると思います：「特定のコードを繰り返し実行したい」

処理する予定のファイルはいくつありますか？

特定のフォルダーには特定のファイル名（拡張子を含む）を1つだけ含めることができるため、これは、コードが1つの適用可能なファイルを見つけることを意図していることを証明します。

これは、すぐに値を返すという事実によっても確認されます。2番目の一致が存在していても、実際には気にしません。

これがアンチパターンではない状況があります。

• サブディレクトリ（Directory.GetFiles(".", SearchOption.AllDirectories)）も調べると、同じファイル名（拡張子を含む）を持つ複数のファイルを見つけることができます。
• 部分的なファイル名の一致を探す場合（たとえば、名前がで始まる"Test_"すべての"*.zip"ファイル、またはすべてのファイル）。

これらのケースはどちらも実際に複数の一致を処理する必要があるため、すぐに値を返さないことに注意してください。

質問2：

2番目の例を修正するには、ifステートメントなしで書き直し、代わりにStreamReaderをtry-catchブロックで囲み、FileNotFoundExceptionをスローする場合は、それに応じてcatchブロックで処理しますか？

例外は高価です。適切な制御ロジックの代わりに使用することはできません。例外は、その名前が例外的な状況を示唆しているためです。

そのため、を削除しないでくださいif。

SoftwareEngineering.SEのこの回答に従って：

一般に、制御フローの例外の使用はアンチパターンであり、顕著な状況固有および言語固有の咳例外の咳があります。

その理由の簡単な要約として、一般的に、それはアンチパターンです：

• 例外は、本質的に、洗練されたGOTOステートメントです
• したがって、例外を伴うプログラミングは、コードの読み取りと理解をさらに困難にします。
• ほとんどの言語には、例外を使用せずに問題を解決するように設計された既存の制御構造があります
• 効率性の引数は、例外が制御フローに使用されないという前提で最適化される傾向にある最近のコンパイラーにとっては重要ではありません。

より詳細な情報については、ウォードのwikiでの議論を読んでください。

これをtry / catchでラップする必要があるかどうかは、状況に大きく依存します。

• 競合状態に遭遇する可能性はどのくらいありますか？
• 実際にこの状況を処理できますか、または処理方法がわからないため、この問題をユーザーに吹き上げますか？

「常にそれを使用する」という問題はありません。私の要点を証明するには：

別の調査では、安全ヘルメット、安全ゴーグル、防弾チョッキを着用すると怪我をする可能性が低いことが証明されています。

では、なぜ私たち全員が常にこの安全装備を着用していないのでしょうか。

簡単な答えは、それらを身に着けることには欠点があるためです：

• お金がかかる
• それはあなたの動きをより面倒にします
• 履くとかなり暖かくなります。

今、私たちはどこかに着いています：長所と短所があります。言い換えれば、プロが短所を上回る場合にのみ、この機器を着用することは理にかなっています。

• 建設作業員は、仕事中に怪我をする可能性がはるかに高くなります。彼らは安全ヘルメットの恩恵を受けています。
• 一方、オフィスワーカーは、けがをする可能性がはるかに低くなります。安全ヘルメットはそれだけの価値はありません。
• SWATチームメンバーは、オフィスワーカーに比べて、撃たれる可能性がはるかに高くなります。

通話をtry / catchでラップする必要がありますか？それは、それを行うことの利点がそれを実装するコストを上回るかどうかに大きく依存します。

それをラップするのに数回のキーストロークしか必要としないと主張する人もいるので、それは明らかに行われるべきであることに注意してください。しかしそれだけではありません。

• 例外をキャッチしたら、何をするかを決める必要があります。
• コードベース全体にわたってさまざまなファイルへのさまざまな呼び出しが多数ある場合、1つをtry / catchでラップすることを決定すると、通常、これらすべてのケースをラップする必要があります。これは、実装に必要な労力に劇的な影響を与える可能性があります。
• 意図的に例外を処理したくない場合は、完全に可能です。
  • アプリケーションはある時点で例外を処理する必要がありますが、例外が発生した直後であるとは限りません。

したがって、選択はあなた次第です。そうすることの利点はありますか？それは、アプリケーションを実装するための労力を費やすよりも、アプリケーションを改善すると思いますか？

更新 -私が書いたコメントから他の回答まで。これもあなたにとって重要な考慮事項だと思います。

それは周囲の状況に大きく依存します。

• streamreaderを開く前にが付いてif(!File.Exists) File.Create()いる場合、streamreaderを開くときにファイルが存在しないことは確かに例外です。
• ファイル名が既存のファイルのリストから選択された場合、その突然の不在は再び例外的です。
• 実際にディレクトリに対してまだテストしていない文字列を使用している場合。ファイルが存在しないことは完全に論理的な結果であり、例外ではありません。