LINQ:不是所有人都不要

Question

通常我想检查提供的值是否与列表中的值匹配(例如,在验证时):

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

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

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

显然,这在逻辑上是相同的,可能稍微更具可读性(如果你已经做了很多数学),我的问题是:这是否会导致性能下降？

它感觉应该是这样(即.Any()听起来像是短路,而.All()听起来不是这样),但我没有任何证据证明这一点.有没有人更深入地了解查询是否会解决相同的问题,或者ReSharper是否让我误入歧途？

Answer 1

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-for-objects.有可能其他一些linq提供者比另一个更好地对待一个,但如果是这样的话,那么它是非常随机的,哪个获得了更优化的实现.

似乎规则只归结为某人感觉if(determineSomethingTrue)更简单,更可读if(!determineSomethingFalse).而且公平地说,我认为它们有点重要,因为我经常会发现if(!someTest)令人困惑的*当有一个相同的冗长和复杂性的替代测试时,我们想要采取行动的条件会恢复正常.但实际上,我个人并没有发现任何一个优于你提供的两个替代方案中的另一个,如果谓词更复杂,也许会略微倾向于前者.

*并不像我不理解那样令人困惑,但令人困惑,因为我担心我不理解的决定有一些微妙的原因,并且需要一些精神上的跳跃才能意识到"不,他们只是决定做就这样,等我再看一下这段代码了什么？......"

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

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 6

根据这个链接

任意–检查至少一场比赛

全部–检查所有匹配项

Answer 7

正如其他答案已涵盖的一样：这与性能无关，而与清晰度有关。

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

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 8

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

一种方法不可能比另一种方法快得多，因为唯一的区别在于布尔否定，所以更喜欢可读性而不是错误的性能胜利。