LINQ: Nie każdy kontra wszyscy nie

Często chcę sprawdzić, czy podana wartość pasuje do wartości na liście (np. Podczas sprawdzania poprawności):

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

Ostatnio zauważyłem, że ReSharper prosi mnie o uproszczenie tych zapytań, aby:

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

Oczywiście jest to logicznie identyczne, być może nieco bardziej czytelne (jeśli zrobiłeś dużo matematyki), moje pytanie brzmi: czy to prowadzi do wydajności?

Wydaje się, że powinien (tzn. .Any()Brzmi jak zwiera, podczas gdy .All()brzmi tak, jakby nie), ale nie mam na to dowodów. Czy ktoś ma głębszą wiedzę, czy zapytania rozwiążą to samo, czy też ReSharper prowadzi mnie na manowce?

Wdrożenie Allzgodnie z ILSpy (jak w rzeczywistości poszedłem i spojrzałem, zamiast „dobrze, ta metoda działa trochę jak ...” Mogę to zrobić, jeśli omawiamy teorię, a nie wpływ).

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

Implementacja Anyzgodnie z 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;
}

Oczywiście może występować niewielka różnica w wytwarzanej IL. Ale nie, nie, nie ma. IL jest prawie taka sama, ale dla oczywistej inwersji zwracania wartości true w przypadku dopasowania predykatu w porównaniu do zwracania wartości false w przypadku niedopasowania predykatu.

Oczywiście jest to tylko linq dla obiektów. Możliwe, że jakiś inny dostawca linq traktuje jednego znacznie lepiej od drugiego, ale jeśli tak było, to raczej losowe, który otrzymał bardziej optymalną implementację.

Wydaje się, że reguła sprowadza się wyłącznie do tego, że ktoś czuje, że if(determineSomethingTrue)jest prostszy i bardziej czytelny niż if(!determineSomethingFalse). I szczerze mówiąc, myślę, że mają one trochę racji w tym, że często mylę się if(!someTest)*, gdy istnieje alternatywny test o równej gadatliwości i złożoności, który zwróciłby prawdę w przypadku warunku, na którym chcemy działać. Ale tak naprawdę, osobiście nie znajduję nic, co by sprzyjało jednej z dwóch alternatyw, które dajesz, i być może pochyliłbym się bardzo nieznacznie do pierwszej, gdyby orzeczenie było bardziej skomplikowane.

* Nie mylące jak w nie rozumiem, ale mylące jak w martwię się, że istnieje jakiś subtelny powód decyzji, której nie rozumiem, i kilka mentalnych przeskoków zdaje sobie sprawę, że „nie, po prostu postanowili to zrobić w ten sposób, poczekaj, po co znów patrzyłem na ten fragment kodu? ... "

Może się okazać, że te metody rozszerzeń czynią kod bardziej czytelnym:

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

Teraz zamiast twojego oryginału

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

można powiedzieć

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

Oba miałyby identyczną wydajność, ponieważ oba zatrzymują wyliczanie po wyniku - Any()na pierwszym elemencie przekazywany predykat ocenia truei All()na pierwszym elemencie, na którym ocenia predykat false.

All zwarcia przy pierwszym braku dopasowania, więc nie stanowi to problemu.

Jednym z obszarów subtelności jest to

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

Jest prawdziwy. Wszystkie elementy w sekwencji są parzyste.

Więcej informacji na temat tej metody można znaleźć w dokumentacji Enumerable.All .

All()określa, czy wszystkie elementy sekwencji spełniają warunek.
Any()określa, czy jakikolwiek element sekwencji spełnia warunek.

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

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

Według tego linku

Dowolny - sprawdza co najmniej jeden mecz

Wszystkie - sprawdza, czy wszystkie pasują

Jak dobrze ujęto inne odpowiedzi: nie chodzi o wydajność, chodzi o przejrzystość.

Istnieje szeroka obsługa obu opcji:

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

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

Myślę jednak, że może to zapewnić szersze wsparcie :

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

Po prostu obliczenie wartości logicznej (i nadanie jej nazwy) przed negowaniem czegokolwiek bardzo to wyjaśnia.

Jeśli spojrzysz na źródło Enumerable , zobaczysz, że implementacja Anyi Alljest dość blisko:

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

Nie ma możliwości, aby jedna metoda była znacznie szybsza od drugiej, ponieważ jedyna różnica polega na boolowskiej negacji, więc wolę czytelność niż fałszywą wydajność.