译:Java局部变量类型推断（Var类型）的26条细则

原文链接：https://dzone.com/articles/va...

作者：Anghel Leonard

译者：沈歌

Java局部变量类型推断（LVTI），简称var类型（标识符var不是一个关键字，是一个预留类型名），Java 10中通过JEP 286: Local-Variable Type Inference 添加进来。作为100%编译特征，它不会影响字节码，运行时或者性能。在编译时，编译器会检查赋值语句右侧代码，从而推断出具体类型。它查看声明的右侧，如果这是一个初始化语句，它会用那个类型取代var。另外，它非常有助于减少冗余代码和样板代码。它还只在旨在编写代码时所涉及的仪式。例如，使用var evenAndOdd=... 代替Map> evenAndOdd... 非常方便。根据用例，它有一个代码可读性的权衡，会在下面第一条中提到。

此外，这里有26条细则，覆盖了var类型的用例，包括它的限制。

1. 争取起有意义的局部变量名

通常我们在起全局变量名的时候会注意这一点，但是选择局部变量名的时候不太注意。尤其是当方法很短，方法名和实现都不错的时候，我们趋向于简化我们的变量名。但是当我们使用var替代显式类型的时候，具体的类型是通过编译器推断出来的。所以，对于人来说阅读或者理解代码非常困难。在这一点上var削弱了代码可读性。这种事情之所以会发生，是因为大多数情况下，我们会把变量类型当成是第一信息，而把变量名当成第二信息。但是使用var的时候，恰恰相反。

示例1

即使到这里，一些朋友仍然坚持局部变量名短点好。我们看一下：

// HAVING
public boolean callDocumentationTask() {
    DocumentationTool dtl = ToolProvider.getSystemDocumentationTool();
    DocumentationTask dtt = dtl.getTask(...);
    return dtt.call();
}

我们换成var时，避免：

// AVOID
public boolean callDocumentationTask() {
    var dtl = ToolProvider.getSystemDocumentationTool();
    var dtt = dtl.getTask(...);
    return dtt.call();
}

更好：

// PREFER
public boolean callDocumentationTask() {
    var documentationTool = ToolProvider.getSystemDocumentationTool();
    var documentationTask = documentationTool.getTask(...);
  return documentationTask.call();
}

示例2：

避免：

// AVOID
public List fetchProducts(long userId) {
    var u = userRepository.findById(userId);
    var p = u.getCart();
    return p;
}

更好：

// PREFER
public List fetchProducts(long userId) {
    var user = userRepository.findById(userId);
    var productList = user.getCart();
    return productList;
}

示例3：

争取为局部变量起有意义的名字并不意味着要掉入过度命名的坑，避免在短方法中使用单一类型的数据流：

// AVOID
var byteArrayOutputStream = new ByteArrayOutputStream();

用如下代码代替更加清晰：

// PREFER
var outputStream = new ByteArrayOutputStream();
// or
var outputStreamOfFoo = new ByteArrayOutputStream();

另外，你知道吗，Java内部使用了一个类名字叫：InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

额。。。命名这个类型的变量是个挑战。

2. 使用数据类型标志来帮助var去推断出预期的基本数据类型(int, long, float, double)

如果在基本数据类型中不使用有效的数据类型标志，我们可能会发现预期的类型和推测出的类型不一致。这是由于var的隐式类型转换导致的。

例如，下面两行代码的表现是符合预期的，首先，我们声明一个boolean 和一个char使用显式类型：

boolean flag = true; // 这是一个boolean类型
char a = 'a';        // 这是一个char类型

现在，我们使用var代替显式基本类型：

var flag = true; // 被推断为boolean类型
var a = 'a';     // 被推断为char类型

到目前为止，一切都很完美。接下来，我们看一下相同逻辑下的int, long, double 和 float:

int intNumber = 20;       // 这是int类型
long longNumber = 20;     // 这是long类型
float floatNumber = 20;   // 这是float类型, 20.0
double doubleNumber = 20; // 这是double类型, 20.0

以上代码是很常见而且清晰的，现在我们使用var:

避免：

// AVOID
var intNumber = 20;    // 推断为int
var longNumber = 20;   // 推断为int
var floatNumber = 20;  // 推断为int
var doubleNumber = 20; // 推断为int

四个变量都被推断成了int。为了修正这个行为，我们需要依赖Java中的数据类型标志。

更好实现:

// PREFER
var intNumber = 20;     // 推断为int
var longNumber = 20L;   // 推断为long
var floatNumber = 20F;  // 推断为float, 20.0
var doubleNumber = 20D; // 推断为double, 20.0

但是如果我们使用小数声明一个数字，会发生什么呢？当你认为你的数字是一个float的时候，避免这样做：

// 避免，如果这是一个float
var floatNumber = 20.5; // 推断为double

你应该用对应的数据类型标志来避免这样的问题：

// 更好, 如果这是一个float
var floatNumber = 20.5F; // 推断为float

3. 在某些情况下，Var和隐式类型转换可以维持可维护性

在某些情况下，Var和隐式类型转换可以维持可维护性。例如，假设我们的代码包含两个方法：第一个方法接收一个包含不同条目的购物卡，比较市场中不同的价格，计算出最好的价格，并汇总返回float类型的总价。另一个方法简单的把这个float价格从卡中扣除。

首先，我们看一下计算最好价格的方法：

public float computeBestPrice(String[] items) {
   ...
   float price = ...;
   return price;
}

然后，我们看一下扣款的方法：

public boolean debitCard(float amount, ...) {
    ...
}

现在，我们把这两个方法汇总，提供一个服务方法。顾客选择要买的商品，计算最优价格，然后扣款：

// AVOID
public void purchaseCart(long customerId) {
    ...
    float price = computeBestPrice(...);
    debitCard(price, ...);
}

一段时间后，公司想要去除价格中的小数部分作为打折策略，使用int代替了float, 我们需要修改代码。

public int computeBestPrice(String[] items) {
   ...
   float realprice = ...;
   ...
   int price = (int) realprice;
   return price;
}
public boolean debitCard(int amount, ...) {
    ...
}

问题在于我们使用了显示类型float，这样的更改不能被兼容。代码会报编译时错误。但是如果我们预判到这种情况，使用var代替float, 我们的代码会因为隐式类型转换而变得没有兼容性问题。

// PREFER
public void purchaseCart(long customerId) {
    ...
    var price = computeBestPrice(...);
    debitCard(price, ...);
}

4. 当数据类型标志解决不了问题的时候，依赖显式向下转换或者避免var

一些Java基础数据类型不支持数据类型标志。例如byte和short。使用显式基础数据类型时没有任何问题。使用var代替的时候：

// 这样更好，而不是使用var
byte byteNumber = 45;     // 这是byte类型
short shortNumber = 4533; // 这是short类型

为什么在这种情况下显式类型比var好呢？我们切换到var.注意示例中都会被推断为int, 而不是我们预期的类型。

避免使用以下代码：

// AVOID
var byteNumber = 45;    // 推断为int
var shortNumber = 4533; // 推断为int

这里没有基础数据类型帮助我们，因此我们需要依赖显示强制类型转换。从个人角度来讲，我会避免这么用，因为没啥好处，但是可以这么用。

如果你真的想用var，这么用:

// 如果你真的想用var，这么写
var byteNumber = (byte) 45;     // 推断为byte
var shortNumber = (short) 4533; // 推断为short

5. 如果变量名没有对人来说足够的类型信息，避免使用var

使用var有助于提供更加简练的代码。例如, 在使用构造方法时（这是使用局部变量的常见示例），我们可以简单地避免重复类名的必要性，从而消除冗余。

避免：

// AVOID
MemoryCacheImageInputStream inputStream = new MemoryCacheImageInputStream(...);

更好：

// PREFER
var inputStream = new MemoryCacheImageInputStream(...);

在下面的结构中，var也是一个简化代码而不丢失信息的好方法。

避免：

// AVOID
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
StandardJavaFileManager fm = compiler.getStandardFileManager(...);

更好：

// PREFER
var compiler = ToolProvider.getSystemJavaCompiler();
var fileManager = compiler.getStandardFileManager(...);

为什么这样基于var的例子我们感觉比较舒服呢？因为需要的信息已经在变量名中了。但是如果使用var 加上变量名，还是会丢失信息，那么最好避免使用var。

避免:

// AVOID
public File fetchCartContent() {
    return new File(...);
}
// As a human, is hard to infer the "cart" type without 
// inspecting the fetchCartContent() method
var cart = fetchCartContent();

使用以下代码代替：

// PREFER
public File fetchCartContent() {
    return new File(...);
}
File cart = fetchCartContent();

思考一个基于java.nio.channels.Selector的例子。这个类有一个静态方法叫做open()，返回一个新的Selector实例并且执行open动作。但是Selector.open()很容易被认为返回一个boolean标识打开当前选择器是否成功，或者返回void。使用var导致丢失信息会引发这样的困扰。

6. var类型确保编译时安全

var类型是编译时安全的。这意味着如果我们试图实现一个错的赋值，会导致编译时报错。例如，以下代码编译不会通过。

// 编译通不过
var items = 10;
items = "10 items"; // 不兼容类型: String不能转为int

以下代码编译会通过

var items = 10;
items = 20;

这个代码也会编译通过：

var items = "10";
items = "10 items" ;

所以，一旦编译器已经推断出了var对应的类型，我们只能赋值对应类型的值给它。

7. var 不能被用于将真实类型的实例赋值给接口类型变量。

在Java中，我们使用“面向接口编程”的技术。

例如，我们创建一个ArrayList的实例，如下(绑定代码到抽象)：

List products = new ArrayList<>();

我们避免这样的事情(绑定代码到实现):

ArrayList products = new ArrayList<>();

所以，通过第一个例子创建一个ArrayList实例更好，但是我们也需要声明一个List类型的变量。因为List是一个接口，我们可以很容易的切换到List的其他实现类，而无需额外的修改。

这就是“面向接口编程”，但是var不能这么用。这意味着当我们使用var时，推断出的类型是实现类的类型。例如，下面这行代码，推测出的类型是ArrayList:

var productList = new ArrayList(); // 推断为ArrayList

以下几个论点支持这一行为：

• 首先，var是局部变量，大多数情况下，“面向接口编程”在方法参数和返回类型的时候更有用。
• 局部变量的作用域比较小，切换实现引起的发现和修复成本比较低。
• var将其右侧的代码视为用于对端实际类型的初始化程序，如果将来修改初始化程序，则推断类型会改变，从而导致后续依赖此变量的代码产生问题。

8. 意外推断类型的可能性

如果不存在推断类型所需的信息，则与菱形运算符组合的var类型可能导致意外推断类型。

在Java 7之前的Coin项目中，我们写了这样的代码:

//显式指定泛型类的实例化参数类型
List products = new ArrayList();

从Java 7开始，我们有了菱形运算符，它能够推断泛型类实例化参数类型：

// inferring generic class's instantiation parameter type 
List products = new ArrayList<>();

那么，以下代码推断出什么类型呢？

首先应该避免这么用：

// AVOID
var productList = new ArrayList<>(); // 推断为ArrayList