TryParse:什么更具可读性

本文关键字：可读性 什么 TryParse | 更新日期: 2023-09-27 17:47:21

Out样式：

bool result;
if(something.TryParse(val, out result))
{
    DoSomething(result);
}

可为空的样式：

bool? result = something.TryParse2(val);
if(result.HasValue)
{
    DoSomething(result.Value);
}

TryParse:什么更具可读性

TryParse（val， out result） 是由 .NET Framework 在 int 中建立的成语。TryParse、DateTime.TryParse等阅读代码的人很可能会熟悉这个成语，所以你应该坚持下去，除非你找到一个很好的理由不这样做。

我并不是要不友善。 但是，当您建议对一个成熟的习语进行更改时，如果您的示例代码不正确，则会破坏信心。

您的第一个示例应该是：

something result;
if (something.TryParse(val, out result))
{
   DoSomething(result);
}

或：

bool result;
if (bool.TryParse(value, out result))
{
    DoSomething(result);
}

第二个示例应该是：

Nullable<something> result = something.TryParse2(val);
if(result.HasValue)
{
    DoSomething(result.Value);
}

或：

bool? result = bool.TryParse2(val);
if (result.HasValue)
{
   DoSomething(result);
}

如果我要为每个值类型实现一个扩展方法，该方法执行您的TryParse2似乎执行的操作，我不会将其称为TryParse2。 现在，如果一个方法的名称以 Try 开头，我们希望它返回一个bool，指示它是成功还是失败。 创建这种新方法将创建一个该期望不再有效的世界。 在你忽略这一点之前，想想当你编写不起作用的示例代码时，你脑子里在想什么，以及为什么你如此确定result需要成为一个bool。

关于你的提议的另一件事是，它似乎试图解决错误的问题。 如果我发现自己写了很多TryParse块，我会问的第一个问题不是"我怎样才能用更少的代码行来做到这一点？ 我会问，"为什么我的解析代码分散在我的应用程序中？ 我的第一直觉是，当我复制所有这些TryParse代码时，我真正想要做的事情是想出一个更高层次的抽象。

我认为风格通常更具可读性。人们不太熟悉可为空的类型（只需在此处查看有关它们的问题数量），并且他们将更不熟悉标准库中不存在的 TryParse2（或者它在技术上是在 .NET 中调用的）。

我可能会使用第二个例子。 虽然我认为两者都是完全可以接受的。

可为空的类型具有同一类型不可为空的 Value 属性。 在这里，您不需要转换可为 null 的类型，而是使用可为 null 类型的值。

我已经看到许多应用程序中使用的out变量语法。

我个人也喜欢它。

我更喜欢第二个示例，因为它是一种对类型推理更友好的编程风格。 具有 out 参数可防止开发人员对特定调用使用类型推断。 


var result = Int32.TryParse("123");

我觉得这两个例子都很笨拙。

我会选择TryParse因为它是.NET Framework中已经存在的习惯用语。

相关文章：