隐式类型如何使代码更清晰？

Question

在我正在阅读的一本书中，它指出隐式类型使以下代码比不使用 var 关键字更清晰：

var words = new[] { "a", "b", null, "d" };

foreach (var item in words)
{
    Console.WriteLine(item);
}

在我看来，情况恰恰相反：如果您使用 string 相反，代码的读者会立即知道它是 foreach 循环中的字符串，而不必在定义变量的代码中查找。

隐式类型如何使上述代码更清晰？

附录

这本书是C # 3.0 - 新的。 schnell + kompakt 是德语，实际文本是：

Das Schluesselwort var kann auch beim Durchlaufen von foreach-Schleifen verwendet werden, um somit den Code uebersichtlicher und einfacher zu gestalten. Besonders bei complexen Typen cann man auf diese Art und Weise Programmierfehler verhindern.

这是我的翻译：

在迭代 foreach 循环时也可以使用 var 关键字，从而使代码的创建更容易、更简单。特别是在使用复杂类型时，这可以防止编程错误。

好吧，现在仔细阅读一下，他实际上指出 foreach 循环中的 var 使代码更容易创建，但不一定更容易阅读。

Answer 1

就我个人而言，我同意你的观点。我不确定我是否会使用“clearer”这个词，但在某些情况下，var关键字肯定可以使其更干净，即：

var myClass = new ExtremelyLongClassNameIWouldntWantToTypeTwice();

Answer 2

我认为奇怪的是，只有 C# 和 Java 程序员似乎遭受了无法从代码上下文中提取信息的困扰，而 Python、JavaScript、Ruby、F#、Haskell 等开发人员似乎对此免疫。为什么他们看起来做得很好，而我们C#程序员却需要讨论这个问题？

如果上述显式类型声明是草率或懒惰的，这是否意味着没有高质量、可读的 Python 代码？其实不是有很多人称赞Python的可读性吗？ JavaScript 中的动态类型有很多让我烦恼的地方，但缺乏显式类型声明并不是其中之一。

静态类型语言中的类型推断应该是常态，而不是例外；它减少了视觉混乱和冗余，同时当您因为想要较少派生的类型而显式指定类型时，使您的意图更加清晰 (IListlist = new List() ;)。

有些人可能会像这样反对 var：

var c = SomeMethod();

嗯，对此我想说你应该给你的变量提供更合理的名称。

改进：

var customer = SomeMethod();

更好：

var customer = GetCustomer();

让我们尝试显式输入：

Customer customer = GetCustomer();

您现在拥有哪些以前没有的信息？您现在可以肯定它的类型是 Customer，但您已经知道了，对吧？如果您已经熟悉代码，那么您只需通过变量名称就可以知道 customer 可以使用哪些方法和属性。如果您还不熟悉代码，您不知道 Customer 有哪些方法。这里的显式类型没有增加任何价值。

也许 var 的一些反对者可能会承认，在上面的例子中，var 没有什么坏处。但是，如果方法不返回简单且众所周知的类型（例如 Customer 或 Order），而是返回一些经过处理的值（例如某种字典）怎么办？比如：

var ordersPerCustomer = GetOrdersPerCustomer();

我不知道返回什么，可能是字典，列表，数组，任何东西。但这有关系吗？从代码中，我可以推断出我将拥有一个可迭代的客户集合，其中每个 Customer 又包含一个可迭代的 Order 集合。 我真的不关心这里的类型。我知道我需要知道什么，如果结果证明我错了，那是该方法的错误，它的名称误导了我，这是无法通过显式类型声明来修复。

让我们看一下明确的版本：

IEnumerable<IGrouping<Customer,Order>> ordersPerCustomer = GetOrdersPerCustomer();

我不了解你，但我发现从中提取我需要的信息要困难得多。至少不是因为包含实际信息（变量名称）的位位于更右侧，在那里我需要花费更长的时间才能找到它，并且在视觉上被所有那些疯狂的 < 和<代码>>。实际类型毫无价值，它是官样文章，特别是因为要理解它，您需要知道那些泛型类型的作用。

如果在任何时候您仅从名称不确定方法的作用或变量包含什么，您应该给它一个更好的名称。这比看看它是什么类型更有价值。

显式类型不应需要，如果需要，则说明您的代码有问题，而不是类型推断有问题。它不可能是需要的，因为其他语言显然也不需要它。

也就是说，我确实倾向于对“基元”使用显式类型，例如 int 和 string。但老实说，这更多的是一种习惯，而不是一个有意识的决定。不过，对于数字，如果您忘记将 m 添加到您想要输入为 decimal 的文字数字，类型推断可能会搞砸您，这很容易做到，但编译器不会允许您意外丢失精度，因此这不是一个实际问题。事实上，如果我在任何地方都使用 var ，那么我所处理的大型应用程序中的数量从整数到小数的更改就会容易得多。

这是 var 的另一个优点：它允许快速实验，而无需强迫您更新各处的类型以反映您的更改。如果我想将上面的示例更改为 Dictionary[]，我可以简单地更改我的实现，并且使用 var 调用它的所有代码将继续工作（好吧，至少是变量声明）。

Answer 3

在这种情况下，情况并非如此，这当然只是我的主观意见。我只在类型位于同一行的其他位置时使用它，例如：

var words = new List<String>();

我喜欢 var，但我不会像在您的示例中那样使用它，因为不清楚类型是什么。

Answer 4

从噪音/冗余更少的意义上来说，它更清晰。编译器和开发人员都可以通过 new[] { ... } 语句轻松推断出单词的类型。因此，使用 var 代替 string[]，因为后者会在视觉上使代码变得混乱。

从透明度的意义上来说，它更加清晰。您可以将实际值与任何其他类型的实例交换，只要它是可枚举类型。如果您没有使用 var，则必须更改示例中的两个声明语句。

它更清晰，因为它迫使您使用好的变量名称。通过使用 var，您无法使用类型声明来指示变量的内容，因此您必须使用描述性名称。一个变量只声明一次，但可能会使用它很多次，所以最好能够通过变量的名称找出变量的内容。从这个角度来看，word 对于循环变量名来说是更好的选择。

请注意，以上推理是从作者的角度进行的。它不一定反映我的个人意见:)

编辑您的附录：

正如我之前提到的，您可以交换底层集合类型，而无需更新所有 foreach 循环。这确实使创建和更改代码变得更容易，但不一定能防止编程错误。在引入 Word 类来替换普通字符串之后，让我们看看这两种情况：

如果我们不使用 var 关键字，编译器会捕获错误：

var words = new[] { new Word("a"), new Word("b"), null, new Word("d") };

// The compiler will complain about the conversion from Word to string,
// unless you have an implicit converion.
foreach (string word in words)
{
    Console.WriteLine(word);
}

如果我们do使用var，代码将编译没有错误，但程序的输出将完全不同，如果 Word 类尚未（正确）实现 ToString()。

var words = new[] { new Word("a"), new Word("b"), null, new Word("d") };

foreach (var word in words)
{
    Console.WriteLine(word); // Output will be different.
}

因此，在某些情况下，当您使用 var 时可能会引入微妙的错误，否则编译器会捕获这些错误。

Answer 5

这里的干净意味着更少的冗余。由于编译器很容易推断出对象的类型是 string[]，因此显式指定它被认为是冗长的。然而，正如您所指出的，对于阅读代码的人来说，这可能不是那么明显。

Answer 6

这个例子很糟糕，就像许多展示语法糖的例子一样 - 语法糖在事情复杂的时候有帮助，但没有人喜欢复杂的例子。

在两种情况下您可能需要使用 var，另一种情况您必须使用：

您可能需要它的情况：

1. 当您在探索自己的代码时快速切换所涉及的类型时，它在实验代码中非常有用。问题空间。
2. 它对于复杂的基于泛型的类型很有用，例如 IGrouping>>，尤其是在复杂的中间状态下发生的情况查询和枚举操作。

就我个人而言，我更喜欢使用复杂的形式而不是 var，因为不关心确切类型的人不需要阅读它（他们可以跳过它，认为“复杂的分组类型”） ），但对于真正关心这个问题的人来说是很清楚的，而无需他们自己解决。

你需要它的地方：

在处理匿名类型时，在如下代码中：

var res = from item in src select new {item.ID, item.Name};    
foreach(var i in res)    
    doSomething(i.ID, i.Name);

这里 res 是匿名类型的 IEnumerable 或 IQueryable，而 i 是该匿名类型。由于该类型没有名称，因此无法显式声明它。

在最后一种情况下，它不是语法糖，但实际上至关重要。

一个相关的抱怨是，SharpDevelop 曾经有自己的 var 编辑时形式；可以输入：

? words = new string[] { "a", "b", null, "d" };

在分号处，编辑器将生成：

string[] words = new string[] { "a", "b", null, "d" };

这提供了（特别是在更复杂的情况下）打字速度以及生成显式代码的优势。他们似乎已经放弃了这一点，因为 var 在概念上做了同样的事情，但遗憾的是失去了显式形式的打字快捷方式。

Answer 7

使用隐式类型是一个指南，而不是法律。

你提出的是一个极端的例子，隐式肯定不理想。

Answer 8

时，它会使代码更清晰

1. 当您有一个名称很长的类
2. 。您有 linq 查询。

Answer 9

在我开始使用 F# 之前，我认为我并没有真正理解 C# 中隐式类型的优点。 F# 具有类型推断机制，在某些方面类似于 C# 中的隐式类型。在 F# 中，类型推断的使用是代码设计的一个非常重要的方面，即使在简单的示例中，它也确实可以使代码更具可读性。学习在 F# 中使用类型推断有助于我理解隐式类型可以使 C# 更具可读性而不是更令人困惑的情况。 （我认为 Linq 的情况相当明显，但很多情况并非如此。）

我意识到这听起来更像是 F# 的插件，而不是问题 re.C# 的答案，但这不是我可以确定的问题一组简单的规则。这是一种在考虑可读性和维护等问题时以新的眼光看待代码的学习。 （那个，也许它是 F# 的一点插件，哈哈。）

Answer 10

如果你想让这段代码更明确，我建议扩展新的而不是删除 var：

var words = new string[] { "a", "b", null, "d" };

Resharper 会提示你删除该示例中的冗余代码，但如果你愿意，你可以关闭这些提示。

使用 var 的理由是，在许多情况下，局部变量的类型标识符是多余的，应该删除多余的代码。通过删除冗余代码，您可以使您真正关心的情况更加清晰，例如，如果您想为局部变量强制执行特定的接口类型：

ISpecificInterface foo = new YourImplementation()

Answer 11

当您需要更改代码时，您必须在更少的地方进行更改。不再有 Dictionary 或更长的类型声明，不再有 Some.Very.Long.Class.With.Very.Long.Path;声明 = functionParameter[index] 等。

尽管我确实同意，当它用于除小方法之外的其他情况时，它可能会变得非常混乱。

Answer 12

在我看来，显式类型的主要好处是，只需查看代码即可确定变量的类型。所以可读性增加了。

隐式类型的主要好处是：

• 减少程序文本，特别是长类型名称（类、接口）的程序文本，从而提高可读性
• 当方法的返回类型更改时，会导致更少的更改。

看起来这两个选项都提高了可读性。

所以我想这取决于您的喜好，也许还取决于您团队中的编程指南。借助 IDE 中当前（重构）工具的支持，更改类型名称变得更加容易（无需动脑筋），因此从工作量角度来看，隐式类型减少更改的原因实际上已经消失。

我建议：做最适合你的事情。没有对错之分。尝试每种方法一段时间（例如，通过配置您最喜欢的重构工具的选项），然后使用使您作为开发人员的生活更轻松的方法。

Answer 13

好吧，您已经掌握了重要的想法 - 过度使用 var 确实可能是有害的，并且在实际类型非常简单的情况下，应该这样声明。

然而，在处理更大的继承层次结构和模板时，var 表现出色。您也可以将其理解为“我不在乎 - 只需给我数据” 虽然 C# 中的模板不具备 C++ 模板的表达能力，但它们确实比 Java 的泛型具有更强的表达能力，这意味着人们如果您必须明确地确定确切的类型，则可以创建不仅尴尬而且难以定位的构造。

例如 - 想象一个围绕几种 DataReader-s 的模板包装器用于与 SQL 对话 - 这样您仍然可以高效（调用存储过程，获取结果，完成），但没有内务处理的负担（关闭读取器和连接，重试或完成）错误等）。使用它的代码将只调用一个函数，该函数具有尽可能短的语法，并且它将返回一个包装器，该包装器的作用类似于 C++ 中的智能指针 - 类似于代码的 DataReader，但也处理所有横向事务。所以它看起来很简单：

using (var r = S.ExecuteReader("[MySproc]", params))
{
    while ((+r).Read())
    (
       // get my data and be done
    )
} // at this point wrapper cleans up everything

在这样的情况下，不仅你不在乎包装器是如何命名和声明的，你甚至不在乎知道它的名称 - 对于你的代码来说它是无关紧要的。你只想要你的该死的数据并继续:-)而不处理任何人的长声明。

它实际上允许您选择何时关心完整类型声明，何时不关心。这不是全有或全无的事情，您会发现自己使用这两种样式。

如果您开始使用 lambda 表达式，您会很高兴拥有它的另一个地方。如果您在 C# 中使用 lambda，几乎总是因为您想要一些简短、紧凑的代码，该代码将运行一次，并且不值得将其转换为常规方法，或者它依赖于宿主方法中的局部变量。

哦，甚至 VS 编辑器也会为你推断完整类型，提供自动完成功能，并在你尝试使用它不能做的事情时抱怨，所以 var 根本不会破坏类型安全（新的 C++ 也得到了 var 的等价物 -早就应该了）。