我经常想检查提供的值是否与列表中的值匹配(例如在验证时):
if (!acceptedValues.Any(v => v == someValue))
{
// exception logic
}
最近，我注意到ReSharper要求我将这些查询简化为:
if (acceptedValues.All(v => v != someValue))
{
// exception logic
}
显然，这在逻辑上是相同的，也许可读性稍强(如果您做了大量的数学运算)，我的问题是:这会导致性能下降吗?
感觉它应该(即. any()听起来像短路，而. all()听起来像没有)，但我没有任何证据来证实这一点。有没有人有更深层次的知识，是否查询将解决相同的，或者ReSharper是否引导我误入歧途?
当前回答
如果你看一下Enumerable源代码，你会发现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;
}
一种方法不可能明显比另一种方法快，因为唯一的区别在于布尔否定，所以更喜欢可读性而不是虚假性能。
其他回答
正如其他答案所涵盖的那样:这与性能无关，而是与清晰度有关。
你的两个选择都得到了广泛的支持:
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
}
在否定任何东西之前简单地计算布尔值(并命名它)在我的脑海中清晰了很多。
第一次不匹配都是短路，所以没问题。
一个微妙的地方是
bool allEven = Enumerable.Empty<int>().All(i => i % 2 == 0);
是真的。序列中的所有项都是偶数。
有关此方法的更多信息，请参阅Enumerable.All的文档。
两者将具有相同的性能，因为两者都在可以确定结果后停止枚举—传递的谓词对第一项的Any()计算为true，而谓词对第一项的All()计算为false。
根据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;
}
根据ILSpy实现Any:
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几乎是相同的，但是对于在谓词匹配时返回真值和在谓词不匹配时返回假值的明显反转而言。
当然，这只是对象的linq。有可能其他的linq提供程序对其中一个的处理要比另一个好得多，但如果是这种情况，那么哪一个得到了更优的实现几乎是随机的。
It would seem that the rule comes down solely to someone feeling that if(determineSomethingTrue) is simpler and more readable than if(!determineSomethingFalse). And in fairness, I think they've a bit of a point in that I often find if(!someTest) confusing* when there's an alternative test of equal verbosity and complexity that would return true for the condition we want to act upon. Yet really, I personally find nothing to favour one over the other of the two alternatives you give, and would perhaps lean very slightly toward the former if the predicate were more complicated.
*困惑不是指我不理解，而是指我担心我不理解的决定中存在一些微妙的原因，并且需要在头脑中跳过几次才能意识到“不，他们只是决定这样做，等等，我为什么要看这段代码?……”
你可能会发现这些扩展方法使你的代码更具可读性:
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
}
