Kotlin作用域函数引发的遮蔽问题

前面讲了kotlin的it变量引起的遮蔽问题，见Kotlin it隐式变量的遮蔽问题，本篇聊聊作用域函数（scoped function）可能引起的遮蔽问题。

先来看一个简单的示例：

fun test(): String {
    val s: String = "asdf".also {
        println(it.length)
    }
    return s
}
1
2
3
4
5
6

这里涉及3个上下文：全局上下文、test函数局部上下文、also引入的上下文。

然后第2个示例：

fun test(): String {
    val s: String = "asdf".apply {
        println(length)
    }
    return s
}
1
2
3
4
5
6

不过这里涉及4个上下文：全局上下文、test函数局部上下文、apply引入的大括号之间的上下文，以及调用apply的字符串对象的对象上下文。

两段程序极为相似，在词法和语法结构上光靠肉眼难以发现差异，但上下文环境却有着较大的差别。在我第一次学习到Kotlin的这个特性时，心里有些不安。

传统的函数式语言中，如Lisp，在使用类似Lambda表达式之类的匿名函数时会引入新的上下文，Java也同理，但不会引入新的对象上下文（Java要同时引入新的函数和对象上下文需要用匿名内部类）。而局部匿名函数在Kotlin中也会引入这个新的函数上下文，却可能引入一个隐式的对象上下文。而这个对象上下文能否观察到、是否醒目就取决于编辑器的提示了。

Kotlin中这样的设计可以让代码变得简洁，但有点过于简洁了，省略了一些有助于阅读的信息，在发生遮蔽的时候有些代码可能反而没有那么直观，比如：

fun test(): String {
    val length = 1
    val s: String = "asdf".apply {
        println(length) // length ?
    }
    return s
}
1
2
3
4
5
6
7

和

class Test {
    val length = 1
    fun test(): String {
        val s: String = "asdf".apply {
            println(length) // length ?
        }
        return s
    }
}
1
2
3
4
5
6
7
8
9

大家可以看出println(length)中的length分别指向哪个对象吗？

所以，我认为作用域函数中引入对象的上下文，有利于简化代码的编写，但是因为其可能导致不易察觉的隐式遮蔽，所以对阅读可能造成影响。甚至，如果经常复制粘贴代码或编写长篇大段的代码，在功能迭代更新时可能因为没有注意到遮蔽的发生而导致bug。

一点点建议

1. 在使用作用域函数（scoped function）时尽量避免多层嵌套，尤其是多个作用域函数嵌套。（一种较为消极且安全的方式）
2. 在引入对象上下文的作用域函数（例如apply）中使用this来引用对象的成员，来减少遮蔽想象的发生，方便阅读，例如：

fun test(): String {
    val length = 1
    val s: String = "asdf".apply {
        println(this.length)
    }
    return s
}
1
2
3
4
5
6
7

3. 避免不同上下文中同名变量的使用。（包括开发者定义的变量和隐式的it）
4. 标准库中的能满足或普通函数就能满足，尽量避免自定义一些作用域函数。
5. 团队中如果不可避免地自定义/扩展了作用域函数，就保持api的稳定，并完善相关文档说明和规范（比如，“新的自定义作用域函数禁止引入对象上下文”或对名称进行规范）