用var声明变量，在java中居然有这么多细节，你都了解么？

简介

Java SE 10引入了局部变量的类型推断。早先，所有的局部变量声明都要在左侧声明明确类型。 使用类型推断，一些显式类型可以替换为具有初始化值的局部变量保留类型var，这种作为局部变量类型 的var类型，是从初始化值的类型中推断出来的。

关于此功能存在一定的争议。有些人对它的简洁性表示欢迎，其他人则担心它剥夺了阅读者看重的类型信息 ，从而损害了代码的可读性。这两边观点都是对的。它可以通过消除冗余信息使代码更具有可读性，也可以 通过删除有用的信息来降低代码的可读性。另外一个观点是担心它会被滥用，从而导致编写更糟糕的Java代码。 这也是事实，但它也可能会导致编写更好的代码。像所有功能一样，使用它必须要判断。何时该使用， 何时不该使用，没有一系列规则。

局部变量声明不是孤立存在的；周边的代码可以影响甚至压倒使用var的影响。本文档的目的是检查周边代码 对var声明的影响，解释一些权衡，并提供有效使用var的指南。

使用原则

P1. 阅读代码比编写代码更重要

代码的读取频率远高于编写代码。此外，在编写代码时，我们通常要有整体思路，并且要花费时间； 在阅读代码的时候，我们经常是上下文浏览，而且可能更加匆忙。是否以及如何使用特定语言功能应该取决 于它对未来读者的影响，而不是它的作者。较短的程序可能比较长的程序更可取，但是过多地简写程序会 省略对于理解程序有用的信息。这里的核心问题是为程序找到合适的大小，以便最大化程序的可读性。

我们在这里特别关注在输入或编写程序时所需要的码字量。虽然简洁性可能会是对作者的一个很好的鼓励，但 专注于它会忽略主要的目标，即提高程序的可读性。

P2. 在经过局部变量类型推断后，代码应该变得清晰

读者应该能够查看var声明，并且使用局部变量声明的时候可以立刻了解代码里正在发生了什么事情。理想 情况下，只通过代码片段或上下文就可以轻松理解代码。如果读懂一个var声明需要读者去查看代码周边的 若干位置代码，此时使用var可能不是一个好的情况。而且，它还表明代码本身可能存在问题。

P3. 代码的可读性不应该依赖于IDE

代码通常在IDE中编写和读取，所以很容易依赖IDE的代码分析功能。对于类型声明，在任何地方使用var,都可以通过IDE指向一个 变量来确定它的类型，但是为什么不这么做呢？

这里有两个原因。代码经常在IDE外部读取。代码出现在IDE设施不可用的许多地方，例如文档中的片段，浏览互联网上的仓库或补丁文件 。为了理解这些代码的作用，你必须将代码导入IDE。这样做是适得其反的。

第二个原因是即使是在IDE中读取代码时也是如此，通常需要明确的操作来查询IDE以获取有关变量的更多信息。例如，查询使用var声明 的变量类型，可能必须将鼠标悬停在变量上并等待弹出信息，这可能只需要片刻时间，但是它会扰乱阅读流程。

代码应该是自动呈现的，它的表面应该是可以理解的，并且无需工具的帮助。

P4. 显式类型是一种权衡

Java历来要求局部变量声明里要明确包含显式类型，显然显式类型可能非常有用，但它们有时候不是很重要，有时候还可以忽略。要求一个 明确的类型可能还会混乱一些有用的信息。

省略显式类型可以减少这种混乱，但只有在这种混乱不会损害其可理解性的情况下。这种类型不是向读者传达信息的唯一方式。其他方法 包括变量的名称和初始化表达式也可以传达信息。在确定是否可以将其中一个频道静音时，我们应该考虑所有可用的频道。

指南 G1. 选择能够提供有用信息的变量名称 通常这是一个好习惯，不过在var的背景下它更为重要。在一个var的声明中，可以使用变量的名称来传达有关变量含义和用法的信息。 使用var替换显式类型的同时也要改进变量的名称。例如：

//原始写法
List<Customer> x = dbconn.executeQuery(query);

//改进写法
var custList = dbconn.executeQuery(query);

在这种情况下，无用的变量名x已被替换为一个能够唤起变量类型的名称custList，该名称现在隐含在var的声明中。 根据方法的逻辑结果对变量的类型进行编码，得出了”匈牙利表示法”形式的变量名custList。 就像显式类型一样，这样有时是有帮助的，有时候只是杂乱无章。在此示例中，名称custList表示正在返回List。这也可能不重要。 和显式类型不同，变量的名称有时可以更好地表达变量的角色或性质，比如”customers”:

//原始写法    
try (Stream<Customer>