在c#中使用var真的那么糟糕吗？

因此，我正在为我的一位同事创建一个连接库，以节省他在当前项目上的时间。我的同事将在他的c#应用程序中使用这个库来连接RESTAPI。在库中，我为每个请求（GET/POST/PUT/DEL）创建了处理程序。当他的应用程序与我的库对话时，我将返回如下响应：

return client.PostAsync(url, content).Result;

var x = API.CreateTraject(parameter1,parameter2);

这将从RESTAPI返回一个动态对象

今天，他使用了我的库，但由于某种原因，无法将它与他的应用程序结合使用。我告诉他使用var，它的工作原理如下：

return client.PostAsync(url, content).Result;

var x = API.CreateTraject(parameter1,parameter2);

他拒绝使用var，最后花了大约40分钟的时间思考如何让它在没有var的情况下工作。然后他责怪我返回了一个动态对象，他永远不会使用var，因为显式更好，所以他告诉我

我通常作为移动开发者（IOS/Android）工作，在那里我一直使用var

现在我的问题是：

---

使用var真的那么糟糕吗？我应该在我的库中转换响应，以便他可以在应用程序中显式地键入它吗？在我看来，我宁愿使用var并节省一些时间，然后花40分钟尝试将其显式化

使用

var

没有什么非法的，它只是让编译器知道对象应该是什么数据类型

唯一的危险是你，程序员，在你鼠标悬停之前不知道它是什么。这可能会导致一些问题，你认为这是一件事，但结果却是另一件事

使用var真的那么糟糕吗？我应该在我的库中转换响应，以便他可以在应用程序中显式地键入它吗？在我看来，我宁愿使用var并节省一些时间，然后花40分钟尝试将其显式化

在C#中，

var

，仅仅是一个编译器“把戏”。不涉及动态类型，编译的代码完全相同。当您将鼠标悬停在变量上时，IDE将告诉您所使用的“真实”类型

无论他使用的是

var

还是您的实际返回类型，对于您如何创建库来说都不重要

如果您的库不必要地返回

dynamic

，则这可能是另一个问题，用户可能会有合理的投诉。与

var

（这只是一个编译时技巧）不同，

dynamic

确实显著地改变了行为

可选地，如果从库中返回匿名类型，您可能需要考虑为您的值创建一个实际类。匿名类型实际上只打算在本地范围内使用，不应该成为任何公共API的一部分。

使用起来不错，只是风格问题。我个人经常使用它，因为它使我所有的变量声明占用相同的空间，而不管类型如何

然而，使用

dynamic

肯定是不好的，特别是当它被过度使用时。这意味着可以在编译时执行的类型安全检查需要推迟到运行时。偶尔这是有用的，但可能会影响性能。除非您真的需要返回动态类型，否则我强烈建议您从API方法返回特定类型

值得一提的是，如果你的同事如此反对隐式键入，他可以使用以下方法：

dynamic x = API.CreateTraject(parameter1,parameter2);

---

var

与

dynamic

无关<代码>变量是关于

类型推断

---

首先，您的方法不应返回

动态

。在任何情况下，创建并让使用者（您的同事）决定该方法将返回什么类型的对象。

可以使用

var

，它不是非法的或任何东西

---

但是我认为如果你知道变量的类型，就用类型来声明变量。这将使您的代码更易于阅读。

谢谢，动态由rest api返回，rest api由我们正在合作的另一家软件公司制作。我觉得返回rest api的响应应该是这样的，如果它通过使用var工作，为什么不呢。@Florianchaal如果它确实是一个动态对象，那么让他使用dynamic，而不是var…好的，但是var是否会使它成为一种强类型，以便在将来的代码中使用？比如说，动态是一个json容器，他需要从中提取数据。@Florianchaal如果你返回动态，var将只是“动态的”——var只是说“使用任何用于初始化我的东西的类型”。啊，好的，这对我来说很清楚！谢谢你提供的信息。我刚才删除的评论正好指出了为什么这类问题没有在这里公开。你在下面得到了很好的信息。读一读，上网，或者买一本书。