扩展 LINQ 以接受可为空的枚举

Question

在使用 Linq 扩展时，看到这样的代码是很正常的：

IEnumerable<int> enumerable = GetEnumerable();
int sum = 0;
if (enumerable != null)
{
    sum = enumerable.Sum();
}

为了提高代码质量，我编写了以下扩展方法，用于检查可空枚举并中断 linq 执行。

public static IEnumerable<T> IgnoreIfEmpty<T>(this IEnumerable<T> enumerable)
{
    if (enumerable == null) yield break;
    foreach (var item in enumerable)
    {
        yield return item;
    }
}

所以，我可以将代码重构为：

var sum = GetEnumerable().IgnoreIfEmpty().Sum();

---

我现在的问题：

1. 我的扩展方法在运行时会受到哪些处罚？
2. 以这种方式扩展 linq 是一种好习惯吗？

更新： 我的目标框架是：3.5

Answer 1

在运行时与我的扩展方法相关的惩罚是什么？

您的扩展方法已转换为状态机，因此开销最小，但这不应该引起注意。

以这种方式扩展 linq 是一种好习惯吗？

在你的问题中你说：

在使用 Linq 扩展时，看到这样的代码是很正常的（在此处插入可枚举的空检查）

我不敢苟同。 常见的做法说don't return null where an IEnumerable<T> is expected。大多数情况应该返回一个空集合（或IEnumerable），将null 留给异常，因为null is not empty。这将使您的方法完全多余。在需要的地方使用Enumerable.Empty<T>。

Answer 2

1. 您将有一个方法调用开销，除非您在紧密循环或性能关键场景中运行它，否则它可以忽略不计。与数据库调用或写入文件系统之类的东西相比，它只是一个影子。请注意，该方法可能不会被内联，因为它是一个枚举器。
2. 一切都与可读性/可维护性有关。当我看到GetEnumerable().IgnoreIfEmpty().Sum(); 时会发生什么？在这种情况下，这是有道理的。

请注意，在 C# 6 中，我们可以使用以下语法：GetEnumerable()?.Sum()，它返回 int?。您可以编写 GetEnumerable()?.Sum() ?? 0 或 GetEnumerable()?.Sum().GetValueOrDefault() 来获取默认为零的非空整数。

如果您真的关心性能，您还可以稍微重构您的方法，使其不是枚举器。这可能会增加内联的机会，尽管我不知道 JIT 编译器的“神秘”逻辑：

public static IEnumerable<T> IgnoreIfEmpty<T>(this IEnumerable<T> enumerable)
{
    if (enumerable == null) return Enumerable.Empty<T>();
    return enumerable;
}

更一般地关于扩展 Linq，我认为只要代码有意义就可以了。 MSDN 甚至有关于它的an article。如果您查看 Linq 中的标准 Where, Select 方法，而忘记它们在其中的性能优化，这些方法大多都是单线方法。

Answer 3

您可以跳过额外的扩展方法并使用null coalescing operator - 这就是它的用途，一次性检查可空性应该比另一个状态机更有效：

IEnumerable<int> enumerable = GetEnumerable();
int sum = 0;

sum = (enumerable ?? Enumerable.Empty<int>()).Sum();

Answer 4

大多数时候，我们编写大量代码只是因为我们被自己的创作之美迷住了——不是因为我们真的需要它——然后​​我们称之为抽象、可重用、可扩展，等等。

这个原始部分是否可读性较差、可扩展性较差、可重用性较差或速度较慢：

var sum = GetEnumerable().Where(a => a != null).Sum(); 

您编写的代码越少 - 您测试的代码越少 - 保持简单。 顺便说一句 - 如果你能证明它是正确的，那么编写扩展方法是很好的。