LINQ: Nicht alle gegen alle nicht

Oft möchte ich überprüfen, ob ein angegebener Wert mit einem in einer Liste übereinstimmt (z. B. bei der Validierung):

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

Kürzlich habe ich festgestellt, dass ReSharper mich gebeten hat, diese Abfragen zu vereinfachen, um:

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

Offensichtlich ist dies logisch identisch, vielleicht etwas besser lesbar (wenn Sie viel Mathematik gemacht haben). Meine Frage lautet: Führt dies zu einem Leistungseinbruch?

Es fühlt sich so an, wie es sollte (dh es .Any()klingt so, als würde es kurzschließen, während es so .All()klingt, als ob es nicht so wäre), aber ich habe nichts, um dies zu begründen. Hat jemand ein tieferes Wissen darüber, ob die Abfragen dasselbe lösen oder ob ReSharper mich in die Irre führt?

Implementierung von Allgemäß ILSpy (wie in Ich habe tatsächlich nachgesehen und nicht nach "Nun, diese Methode funktioniert ein bisschen wie ...", was ich tun könnte, wenn wir eher die Theorie als die Auswirkungen diskutieren würden).

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

Implementierung von Anynach 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;
}

Natürlich könnte es einen subtilen Unterschied in der produzierten IL geben. Aber nein, nein gibt es nicht. Die IL ist ziemlich gleich, aber für die offensichtliche Umkehrung der Rückgabe von true bei Prädikatübereinstimmung gegenüber der Rückgabe von false bei Prädikatfehlanpassung.

Dies ist natürlich nur Linq-for-Objects. Es ist möglich, dass ein anderer Linq-Anbieter einen viel besser behandelt als den anderen, aber wenn dies der Fall ist, ist es ziemlich zufällig, welcher die optimalere Implementierung erhalten hat.

Es scheint, dass die Regel nur auf jemanden zurückzuführen ist, der das Gefühl hat, if(determineSomethingTrue)einfacher und lesbarer zu sein alsif(!determineSomethingFalse) . Und fairerweise denke ich, dass sie einen gewissen Punkt haben, den ich oft if(!someTest)verwirrend finde *, wenn es einen alternativen Test von gleicher Ausführlichkeit und Komplexität gibt, der für die Bedingung, auf die wir reagieren wollen, wahr ist. Ich persönlich finde jedoch nichts, was eine der beiden von Ihnen angegebenen Alternativen gegenüber der anderen bevorzugt, und würde mich vielleicht ganz leicht zu der ersteren neigen, wenn das Prädikat komplizierter wäre.

* Nicht verwirrend wie in Ich verstehe nicht, aber verwirrend wie in Ich mache mir Sorgen, dass es einen subtilen Grund für die Entscheidung gibt, den ich nicht verstehe, und es braucht ein paar mentale Sprünge, um zu erkennen, dass "Nein, sie haben sich einfach dazu entschlossen Warten Sie auf diese Weise, worauf habe ich diesen Code noch einmal angeschaut? ... "

Diese Erweiterungsmethoden machen Ihren Code möglicherweise besser lesbar:

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

Jetzt anstelle Ihres Originals

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

du könntest sagen

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

Beide haben die gleiche Leistung, da beide die Aufzählung beenden, nachdem das Ergebnis bestimmt werden kann - Any()beim ersten Element wird das übergebene Prädikat ausgewertet trueund All()beim ersten Element wird das Prädikat ausgewertet false.

All Kurzschlüsse bei der ersten Nichtübereinstimmung, daher ist dies kein Problem.

Ein Bereich der Subtilität ist das

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

Ist wahr. Alle Elemente in der Sequenz sind gerade.

Weitere Informationen zu dieser Methode finden Sie in der Dokumentation zu Enumerable.All .

All()bestimmt, ob alle Elemente einer Sequenz eine Bedingung erfüllen.
Any()bestimmt, ob ein Element einer Sequenz die Bedingung erfüllt.

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

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

Nach diesem Link

Beliebig - Überprüft mindestens ein Spiel

Alle - Überprüft, ob alle übereinstimmen

Wie andere Antworten bereits ausführlich dargelegt haben: Hier geht es nicht um Leistung, sondern um Klarheit.

Es gibt breite Unterstützung für beide Optionen:

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

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

Aber ich denke, dies könnte eine breitere Unterstützung erreichen :

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

Einfach den Booleschen Wert zu berechnen (und ihn zu benennen), bevor etwas negiert wird, macht dies in meinem Kopf sehr deutlich.

Wenn Sie sich die Enumerable-Quelle ansehen, werden Sie feststellen, dass die Implementierung von Anyund Allziemlich nah ist:

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

Es gibt keine Möglichkeit, dass eine Methode wesentlich schneller als die andere ist, da der einzige Unterschied in einer booleschen Negation liegt. Ziehen Sie daher die Lesbarkeit dem falschen Leistungsgewinn vor.