不要再用var扼杀了代码的阅读性

前言

var 是一种在许多编程语言中被广泛使用的类型推断关键字,允许程序员在声明变量时不需要明确指定变量的类型,而是让编译器根据赋值语句右侧的表达式自动推断变量的类型。这种特性通常被称为"局部变量类型推断"(Local Variable Type Inference)。
优势

  • 简洁性和可读性var 的类型推断使代码更简洁,减少了冗余的类型信息,提高了代码的可读性,尤其是对于较长的类型名或复杂类型的情况。
  • 易于重构:当需要更改变量的类型时,只需修改赋值语句右边的表达式,而不需要手动修改变量的声明,这样更容易进行代码重构。
  • 适用于复杂类型 :对于复杂的泛型类型或匿名类型,使用 var 可以避免手动书写复杂的类型名。
  • 更快的开发速度:在编写代码时不必考虑每个变量的具体类型,可以更快地编写代码并进行迭代开发。

劣势

需要注意的是,尽管 var 提供了便利,但过度使用可能会降低代码的可读性。

为什么会降低代码可读性呢?

dart 复制代码
final String text = 'hello world'; 
final TextEditingController controller = TextEditingController(); 

var text = '123'; 
var controller = TextEditingController();

像上述代码展示了使用 var 和不使用 var 时的区别。使用 var 可使代码更简洁,通过赋值表达式即可明确变量的类型,减少类型声明的冗余。当然,对于不可变的情况,使用 final 更恰当。然而,当赋值表达式右侧不是直接的数值或对象创建,而是通过方法调用等方式获取对象呢?

dart 复制代码
var result = feedbackManager.upload(); // 什么是 result 的类型?

在这个示例中,如果 upload 返回一个复杂对象,而且没有注释或文档来解释 result 的类型,阅读代码的人可能需要查看 upload 的实现才能确定 result 的类型。这可能会降低代码的可读性。

如果像这样的例子充斥在某个方法中,则要阅读该代码的难度将大大提升。

假设我们有一个方法,该方法用于解析一个 JSON 字符串并进行处理。在方法中,大量使用 var 声明变量,没有显式指定类型。

dart 复制代码
void processJson(String jsonString) {
  var decodedJson = jsonDecode(jsonString);
  var data = decodedJson['data'];
  var totalItems = data['totalItems'];
  var itemList = data['items'];

  for (var item in itemList) {
    var itemId = item['id'];
    var itemName = item['name'];

    // 一些处理逻辑
  }
  
  // 更多处理逻辑
}

在这个示例中,大量使用了 var 来声明变量,但没有明确指定它们的类型。这使得阅读代码的人需要仔细查看代码以确定每个变量的类型,尤其在 JSON 结构较为复杂时。

相反,如果我们使用显式类型声明:

dart 复制代码
void processJson(String jsonString) {
  Map<String, dynamic> decodedJson = jsonDecode(jsonString);
  var data = decodedJson['data'];
  int totalItems = data['totalItems'];
  List<dynamic> itemList = data['items'];

  for (Map<String, dynamic> item in itemList) {
    int itemId = item['id'];
    String itemName = item['name'];

    // 一些处理逻辑
  }
  
  // 更多处理逻辑
}

在这个版本中,阅读代码的人可以立即了解每个变量的类型,无需额外的推断或查找。这提高了代码的可读性,特别是在大型代码库或团队协作的情况下。

var 带来的代码可读性降低主要体现在以下方面:

  1. 失去显式类型信息 : 显式声明变量的类型能够让代码阅读者清晰地了解该变量的数据类型,而使用 var 将类型信息隐藏起来,使得在阅读代码时不容易确定变量的具体类型。这可能导致理解代码所需的时间增加,尤其是在处理复杂表达式或方法调用时。
  2. 上下文不清晰 : 当赋值表达式的右边是一个复杂的方法调用、函数返回、或者多步运算时,var 的使用可能使得上下文变得模糊。阅读者可能需要查看赋值语句右边的代码才能理解变量的类型,这增加了理解代码的难度。
  3. 过度使用 : 如果过度使用 var ,特别是在一个方法或代码块中大量使用,可能会使代码难以维护和阅读。过多的 var 可能会掩盖代码中的实际逻辑,使得其他开发人员或你自己在后期难以理解代码。

为了维护良好的代码可读性,建议在以下情况明确使用 var

  • 赋值表达式的右边是明确的、简单的初始化表达式,如基本数据类型、字符串、对象创建等。
  • 对于复杂的初始化表达式,可以使用 var,但要确保代码仍然具有清晰的可读性,可能需要适当的注释来解释类型。

一些情况下,尽管 var 确实可以使代码更简洁,但如果这种简洁性以牺牲代码可读性为代价,应该慎重考虑并选择明确的类型声明。在实际编码中,平衡代码的简洁性和可读性非常重要。

相关推荐
方圆想当图灵1 天前
由 Mybatis 源码畅谈软件设计(九):“能用就行” 其实远远不够
后端·代码规范
古拉拉明亮之神4 天前
scala的统计词频
scala·命令模式·代码规范·源代码管理
沉默是金~5 天前
Vue 前端代码规范
前端·vue.js·代码规范
CreditFE信用前端7 天前
如何更好的应对技术债?
程序员·架构·代码规范
litGrey9 天前
【规范七】Git管理规范
git·代码规范
三原9 天前
写给我前端同事,从事一年多应该要怎么成长的路线
前端·代码规范
方圆想当图灵9 天前
由 Mybatis 源码畅谈软件设计(三):简单查询 SQL 执行流程
后端·代码规范
看山还是山,看水还是。11 天前
软件工程 设计的复杂性
笔记·流程图·软件工程·团队开发·代码规范·内容运营·代码覆盖率
古拉拉明亮之神11 天前
Scala的链式风格
scala·命令模式·代码规范·源代码管理
狂炫一碗大米饭12 天前
响应式设计:打造一个自动适应用户设备屏幕大小和方向的页面。
前端·javascript·代码规范