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 майже однаковий, але для очевидної інверсії повернення істини на предикатну відповідність проти повернення false в невідповідності присудка.

Це звичайно лише linq-for-objects. Цілком можливо, що якийсь інший постачальник 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;
}

Немає можливості, щоб один метод був значно швидшим, ніж інший, оскільки єдина відмінність полягає у бульовому запереченні, тому віддайте перевагу читабельності над хибною програмою win win.