LINQ：不是任何人都不是所有人

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

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

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

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

显然，这在逻辑上是相同的，也许可读性更高（如果您完成了许多数学运算），我的问题是：这会导致性能下降吗？

感觉像是应该的（即.Any()听起来像是短路，而.All()听起来像不是），但是我没有任何证据可以证明这一点。是否有人对查询是否可以解决相同的问题或ReSharper是否使我误入歧途有更深入的了解？

All根据ILSpy的实现（就像我实际去看的那样，而不是“嗯，这种方法的工作原理类似于……”，如果我们在讨论理论而不是影响，我可能会这样做）。

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;
}

实施Any根据ILSpy：

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提供程序可能会比另一种更好地对待它，但是如果是这种情况，哪个获得了最佳实现是非常随机的。

似乎规则完全归因于某人感觉if(determineSomethingTrue)比if(!determineSomethingFalse)。公平地说，我认为它们有一点意义，即if(!someTest)当对相同的冗长性和复杂性进行另类测试时，对于我们要采取的条件返回真实值时，我常常会感到困惑*。但是，实际上，我个人没有发现哪一种可以比您提供的两种选择中的另一种更好，并且如果谓词更复杂，则可能会略微倾向于前者。

*不要因为我不明白而感到困惑，但是因为担心我不明白的决定有一些微妙的原因而使我感到困惑，并且需要花些时间跳过才能意识到“不，他们只是决定做这样，等我又在看这段代码吗？...”

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

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
}

双方将具有相同的性能，因为结果后都停止计数可确定- Any()第一个项目所传递的谓词为true与All()第一项的断言求false。

All 第一次不匹配时发生短路，因此这不是问题。

一个微妙的领域是

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

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

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

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

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

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

根据这个链接

任意–检查至少一场比赛

全部–检查所有匹配项

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

这两种选择均得到广泛支持：

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
}

在否定任何东西之前简单地计算布尔值（并将其命名）就可以在我的脑海中解决这个问题。

如果你在看看可枚举源你会看到的实施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;
}

一种方法不可能比另一种方法快得多，因为唯一的区别在于布尔取反，因此更喜欢可读性而不是错误的性能。