LINQ：不是任何与全部不

Question

我经常想检查提供的值是否与列表中的一个匹配（例如，在验证时）：

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

最近，我注意到 ReSharper 要求我将这些查询简化为：

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

显然，这在逻辑上是相同的，也许更具可读性（如果您'我做了很多数学工作），我的问题是：这会导致性能下降吗？

感觉应该如此（即 .Any() 听起来像是短路，而 .All() 听起来好像没有），但我没有什么可以证实的这。有谁对查询是否会解决相同的问题有更深入的了解，或者 ReSharper 是否让我误入歧途？

Answer 1

根据 ILSpy 实现 All （就像我实际上去查看了一样，而不是“嗯，该方法的工作原理有点像......”如果我们讨论的是理论而不是实际情况，我可能会这样做影响）。

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (!predicate(current))
        {
            return false;
        }
    }
    return true;
}

根据 ILSpy 实现 Any：

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null)
    {
        throw Error.ArgumentNull("source");
    }
    if (predicate == null)
    {
        throw Error.ArgumentNull("predicate");
    }
    foreach (TSource current in source)
    {
        if (predicate(current))
        {
            return true;
        }
    }
    return false;
}

当然，生成的 IL 可能存在一些细微的差异。但不，不，没有。 IL 几乎是相同的，但在谓词匹配时返回 true 与在谓词不匹配时返回 false 之间存在明显的反转。

当然，这只是 linq-for-objects。某些其他 linq 提供程序可能会比另一个提供程序更好地对待其中一个，但如果是这种情况，则哪个提供程序获得更优化的实现几乎是随机的。

看起来这条规则只是因为有人觉得 if(defineSomethingTrue) 比 if(!defineSomethingFalse) 更简单、更易读。公平地说，我认为他们有一点道理，因为我经常发现 if(!someTest) 令人困惑*，当存在同等冗长和复杂性的替代测试时，该测试将为条件返回 true我们希望采取行动。但实际上，我个人认为您提供的两种选择中没有什么比另一种更有利的，并且如果谓词更复杂，也许会稍微倾向于前者。

*不是令人困惑，因为我不明白，而是令人困惑，因为我担心这个决定有一些我不理解的微妙原因，并且需要一些精神跳跃才能意识到“不，他们只是决定这样做”就这样，等等，我又在看这段代码做什么？...”

Answer 2

您可能会发现这些扩展方法使您的代码更具可读性：

public static bool None<TSource>(this IEnumerable<TSource> source)
{
    return !source.Any();
}

public static bool None<TSource>(this IEnumerable<TSource> source, 
                                 Func<TSource, bool> predicate)
{
    return !source.Any(predicate);
}

而不是原来的

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

现在您可以说

if (acceptedValues.None(v => v == someValue))
{
    // exception logic
}

Answer 3

两者将具有相同的性能，因为两者在确定结果后都停止枚举 - 在传递谓词的第一个项目上的 Any() 计算结果为 true 和 All() 在第一个项目上，谓词计算结果为 false。

Answer 4

All 在第一次不匹配时发生短路，所以这不是问题。

一个微妙的地方是这

 bool allEven = Enumerable.Empty<int>().All(i => i % 2 == 0); 

是真的。序列中的所有项目都是偶数。

有关此方法的详细信息，请参阅 Enumerable.All 的文档。

Answer 5

正如其他答案已经很好地涵盖的那样：这与性能无关，而是与清晰度有关。

您的两种选择都得到了广泛的支持：

if (!acceptedValues.Any(v => v == someValue))
{
    // exception logic
}

if (acceptedValues.All(v => v != someValue))
{
    // exception logic
}

但我认为这可能会获得更广泛的支持：

var isValueAccepted = acceptedValues.Any(v => v == someValue);
if (!isValueAccepted)
{
    // exception logic
}

在否定任何内容之前简单地计算布尔值（并命名它）可以在我的脑海中清除很多东西。

Answer 6

如果您查看 Enumerable 源，您会发现将看到 Any 和 All 的实现非常接近：

public static bool Any<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    foreach (TSource element in source) {
        if (predicate(element)) return true;
    }
    return false;
}

public static bool All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate) {
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    foreach (TSource element in source) {
        if (!predicate(element)) return false;
    }
    return true;
}

一种方法不可能比另一种方法明显快，因为唯一的区别在于布尔否定，所以更喜欢可读性胜过虚假性能。

Answer 7

All() 确定序列中的所有元素是否满足条件。
Any() 确定序列中的任何元素是否满足条件。

var numbers = new[]{1,2,3};

numbers.All(n => n % 2 == 0); // returns false
numbers.Any(n => n % 2 == 0); // returns true

Answer 8

根据此链接< /a>

任意 - 检查至少一个匹配项

全部 - 检查是否全部匹配