where条件とcontinueガード句を使用したforeachループのフィルタリング

私はこれを使用するプログラマを見てきました：

foreach (var item in items)
{
    if (item.Field != null)
        continue;

    if (item.State != ItemStates.Deleted)
        continue;

    // code
}

私が通常使用する代わりに：

foreach (var item in items.Where(i => i.Field != null && i.State != ItemStates.Deleted))
{
    // code
}

私は両方の組み合わせを見てきました。「継続」、特により複雑な条件での読みやすさが本当に好きです。パフォーマンスに違いはありますか？データベースクエリを使用すると、あると想定しています。通常のリストはどうですか？

これは、コマンド/クエリの分離を使用する適切な場所と見なします。例えば：

// query
var validItems = items.Where(i => i.Field != null && i.State != ItemStates.Deleted);
// command
foreach (var item in validItems) {
    // do stuff
}

これにより、クエリ結果に適切な自己文書化名を付けることもできます。また、両方を実行しようとする混合コードよりも、データのみを照会するか、データのみを変更するコードをリファクタリングする方がはるかに簡単なので、リファクタリングの機会を見つけるのにも役立ちます。

デバッグするときは、前foreachに中断して、内容がvalidItems期待どおりに解決するかどうかをすばやく確認できます。必要な場合を除き、ラムダにステップインする必要はありません。ラムダにステップインする必要がある場合は、それを別の関数にファクタリングし、代わりにステップスルーすることをお勧めします。

パフォーマンスに違いはありますか？クエリがデータベースによってバックアップされている場合は、LINQのバージョンがあり潜在的な SQLクエリがあるため、より高速に実行することがより効率的にします。LINQ to Objectsの場合、実際のパフォーマンスの違いは見られません。いつものように、事前に最適化を予測しようとするのではなく、コードのプロファイルを作成し、実際に報告されるボトルネックを修正します。

もちろん、パフォーマンスには違いがあり、.Where()すべてのアイテムに対してデリゲート呼び出しが行われます。ただし、パフォーマンスについてはまったく心配しません。

• デリゲートの呼び出しで使用されるクロックサイクルは、コレクションを反復処理して条件をチェックする残りのコードで使用されるクロックサイクルと比較して無視できます。

• デリゲートを呼び出すことによるパフォーマンスの低下は、数クロックサイクルのオーダーであり、幸いなことに、個々のクロックサイクルを心配しなければならなかった時代はずっと過ぎています。

^{何らかの理由でパフォーマンスがある場合は、本当にクロックサイクルレベルでのあなたのために重要な、そして使いList<Item>の代わりをIList<Item>するので、コンパイラは、直接（とINLINABLE）を利用できることは、仮想呼び出しの代わりに呼び出す、とのイテレータているのでList<T>、実際に、 、structボックス化する必要はありません。しかし、それは本当に些細なことです。}

データベースクエリは、（少なくとも理論的には）RDBMSにフィルターを送信する可能性があるため、パフォーマンスが大幅に向上するため、状況は異なります。一致する行のみがRDBMSからプログラムに移動します。しかし、そのためにはlinqを使用する必要があると思いますが、この式をそのままRDBMSに送信できるとは思いません。

if(x) continue;このコードをデバッグする必要がある瞬間の利点が本当にわかります。s if()とcontinues のシングルステップ実行はうまく機能します。フィルタリングデリゲートへのシングルステップは苦痛です。