linq - 使用 LINQ 和 ReSharper 时如何摆脱 "Possible System.NullReferenceException"警告？

Question

假设我有以下代码:

public class Deck {
  [NotNull IEnumerable<Card> cards = new List<Cards>();
  [NotNull] public IEnumerable<Card> Cards { get; private set; }

  public void AddCard([NotNull] Card card) { cards.Add(card); }
  ...
}

public static IEnumerable<int> CardValuesOfColor(this Deck deck, Color color)
{
  var cards = deck.Cards;
  return cards.Where(c => c.Color == color).Select(c => c.Value);
}

运行 ReSharper 代码检查时，它正确地提示“deck.Cards”处可能出现 System.NullReferenceException，因为在此代码中 deck 可能为 null。这是个好东西，我想保留这个。

但是，它也会提示 c.Color 和 c.Value，因为它感觉 c 在这些情况下可能为 null。这似乎过分而且没有帮助。

我可以通过将 lambda 从“c.Color == color”更改为“c != null && c.Color == color”来“修复”c.Color，尽管这对每个 Where 子句来说都很痛苦，特别是当我从类设计中知道 deck.Cards 不会包含空值时。

这并没有解决 c.Value 问题，即使很明显在修改后的“where”子句之后，c 不可能为 null。

似乎没有办法在不触发此警告的情况下编写 Select(...)、OrderBy(...) 等子句。

当我打开在我的项目中寻找可能的空引用时，我得到了数百个有“问题”的文件。我们广泛使用 LINQ，这些“问题”中有很多(但不是全部)是虚假的，但无法关闭。

我的选择似乎是关闭可能的空引用检查或使用注释对每次使用 LINQ 的 Select() 扩展进行注释。这两者都不适合我。

是否有第三种选择可以解决这个问题？

Answer 1

您必须牢记，ReSharper 是一种静态代码分析工具，即它会在不考虑代码上下文的情况下查看代码中的模式，然后根据某人的意见提出“改进”或“修复”建议ReSharper(或者您自己，如果您自定义了设置)认为“更好”。

静态分析的问题在于它对您的代码的意图没有概念，因此您可以保证它有时会建议实际上使您的代码变得更糟的“改进”，因为它缺乏适合的上下文您的代码试图表达的含义。

这与“每条规则都有异常(exception)”的论点相同，使用 ReSharper 等工具的人(比如我)不应盲目地遵循这些建议。

相关说明:代码契约将帮助您解决问题