“如果”条件比 ??和铸造答案

【问题标题】：Is “If” condition better than ?? and casting“如果”条件比 ??和铸造
【发布时间】：2012-12-04 08:01:04
【问题描述】：

对于相同的功能，我有以下两种方法 - 一种使用“if”条件，一种使用“??和铸造”。哪种方法更好？为什么？

代码：

  Int16? reportID2 = null;
  //Other code

  //Approach 1
  if (reportID2 == null)
  {
       command.Parameters.AddWithValue("@report_type_code", DBNull.Value);
  }
  else
  {
     command.Parameters.AddWithValue("@report_type_code", reportID2);
  }

  //Approach 2
  command.Parameters.AddWithValue("@report_type_code", ((object) reportID2) ?? DBNull.Value);

更新

根据回答，以下是??的好处

提高了可读性
减少程序流的分支深度（降低圈复杂度）

注意：转换为对象的成本可以忽略不计。

参考

Null-Coallescing Operator - Why Casting?

【问题讨论】：

我会留下null-col-op、performance和casting标签。

标签： c# performance casting null-coalescing-operator

【解决方案1】：

空合并运算符 (??) 是一种更好的方法，因为它与您的初始块执行相同的操作，但在一个易于阅读的行中。 这使代码更具可读性和可维护性。

这是语法糖的众多示例之一，也就是说，代码语句是表示常用想法的“快捷方式”。i++ 是另一个示例，因为它取代了i = i + 1。它更干净更简单，就像??。

【讨论】：

对不起，你错了，switch 是一个跳转表，而不是简单的 if！这就是只允许使用简单值的原因。
@FelixK.: 对于小于 4 的 switch-case - 它只是 if-else（由编译器解包）
@FelixK。 IMO 这只是一个实施细节。允许编译器将多个ifs变成一个跳转表，一个switch变成多个ifs。
@FelixK。 - 在阅读您的评论之前，我实际上更改了示例，因为我认为 i++ 是一个更简单的比较，更类似于 ?? - 希望这不那么“有争议”。
@CodesInChaos 你是对的，但在大多数情况下，当你需要一个开关（即在枚举上进行开关）时，他们应该在它后面创建一个跳转表，这取决于实现更快（我不要认为实施太糟糕了）。 en.wikipedia.org/wiki/Switch_statement

【解决方案2】：

在这种情况下，我总是使用null-coalescing operator：

command.Parameters.AddWithValue("@name", value ?? DBNull.Value);

command.ExecuteScalar() as int? ?? -1;

等等

它增加了代码的可读性，减少了分支深度。还专为与数据库相关的场景（例如 ADO.NET）而创建。

【讨论】：

为什么你认为这样更好？
由于这里的整个想法是比较不同方法的可读性，因此将排除项排除在外并不能使其成为公平的比较。
我也不确定转换为对象会花费什么。
@Lijo 1) 由于AddWithValue 采用object，它总是会导致装箱，因此您的方法不会节省任何东西。无论哪种方式，您都会为每个参数获得一个装箱操作。转换为对象不是免费的，因为对象需要稍后收集，但它也不太昂贵。 2) 与数据库查询的成本相比，一些框可以忽略不计。
@Lijo 还有什么？您的两种方法之间除了编码风格之外没有其他区别。所以只有可读性、可维护性等很重要，这些都是非常相关的概念。

【解决方案3】：

在您的示例中，方法 2 更好。你should not repeat yourself，apprach 1 有两次代码和参数名称。如果要更改参数名称，则应在两个地方进行，这很麻烦。

与之比较的真正代码是这样的：

object value = DBNull.Value;
if (reportID2 != null)
{
    value = reportID2;
}
command.Parameters.AddWithValue("@report_type_code", value);

如果你使用这个或?? 操作符是个人喜好的问题。我认为if 更清晰，尤其是因为在合并运算符的情况下需要括号和强制转换。

【讨论】：

没有。在这种情况下，您不必担心性能。差异可以忽略不计。
如果您同意，您能否通过以下详细信息改进您的答案？ 1) 方法 2 更具可读性 2) AddWithValue 总是导致作为对象装箱 3) 转换为对象成本不高。

【解决方案4】：

我更喜欢?? 运算符。虽然简洁并不总能带来更好的可读性，但在这种情况下确实如此，因为作为读者，您不必比较 if 和 else 两行之间的相同和不同之处。此外，您消除了重复代码（这总是好的！）。考虑将数据库字段名称重命名为@report_type_code 的情况。然后你只需要在一个地方改变它。

【讨论】：