使用where条件vs 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解析的内容是否符合您的期望。除非需要，否则您不必进入lambda。如果确实需要进入lambda，则建议将其分解为一个单独的函数，然后逐步执行。

性能上有区别吗？如果查询由数据库支持，则LINQ版本可能会运行得更快，因为SQL查询可能更有效。如果是LINQ to Objects，那么您将看不到任何实际的性能差异。与往常一样，分析您的代码并修复实际报告的瓶颈，而不是尝试预先预测优化。

当然，性能上会有差异，.Where()导致对每个项目都进行委托调用。但是，我完全不用担心性能：

• 与其余遍历集合并检查条件的代码所用的时钟周期相比，调用委托所使用的时钟周期可以忽略不计。

• 调用代表的性能损失大约是几个时钟周期，幸运的是，我们已经过了很长时间才不得不担心各个时钟周期的问题。

^{如果出于某种原因，性能在时钟周期级别上对您而言确实很重要，请使用List<Item>代替IList<Item>，以便编译器可以使用直接（且不可插入）调用代替虚拟调用，从而使的迭代器List<T>实际上是一个struct，不必装箱。但这确实是一件小事。}

数据库查询是另一种情况，因为（至少在理论上）有可能将过滤器发送到RDBMS，从而大大提高了性能：只有匹配的行才能从RDBMS到您的程序。但是为此，我认为您必须使用linq，我不认为此表达式可以按原样发送到RDBMS。

您真的会if(x) continue;在需要调试该代码的那时候看到好处：单步执行if()s和continues可以很好地工作；单步进入过滤委托很痛苦。