新手问题关于阅读 / 查看「动态语言」源代码，这个问题怎么解决？

jcd · 2015年03月14日 · 最后由 billy 回复于 2015年04月14日 · 2538 次阅读

动态语言，比如 ruby. 阅读源代码总是挺虐心的，因为你不能轻易知道方法/函数的返回值和参数分别是什么数据类型的！有时候甚至看遍整个方法的代码去猜测参数是什么类型的，返回值又是什么类型的。所以有时候可能就多此一举地在定义方法时描述一下：

# params: A: string, B: float
# return: instance of ClassX
def wtf(A, B)
...
end

# 该传 interger 的  id 呢还是 string 的  id ?
def process(id)
...
end

可不是每个人都那么有闲功夫的。还是这就是个无奈之举，你们平时是怎么解决的？

虽然这个问题对于 ruby 这种纯 OO 比其它不纯 OO 的语言要轻松些。

2 个赞

huacnlee #1 2015年03月14日

调用一下就知道了，再说，一般文档都有写的

jcd #2 2015年04月13日

有人出现成方案了：https://github.com/gogotanaka/Rubype 虽然有点繁琐，但是很不错！真的。

lyfi2003 #3 2015年04月13日

我觉得这是个伪问题。

参数一定会声明的有意义，例如：

Array#abbrev(pattern = nil)

我马上就知道这个 pattern 是什么类型了啊，反而像静态语言那种太繁琐。

chenge #4 2015年04月13日

最近看到 coursera 介绍 scala，据说重构方便。这方面 Ruby 也缺乏支持。感觉 Ruby 对中小型项目还是不错的，比较轻便。大项目会有诸多不便。

amcsc #5 2015年04月13日

动手操作一下分别传不同的参数，.class 不就知道了嘛

forests #6 2015年04月14日

小小的建议下：与其痛苦地纠结变量的数据类型，还不如像 Duck Typing 那样只关心行为。

deathking #7 2015年04月14日

我记得 Ruby 的文档都是会给使用范例的，类型什么的文档都说得很清楚。

我感觉 Rubype 并不是真正意义上的 Gradual Type Checking，它只能算是一个 framework，本质上也是一个动态类型检查，只不过它把本来应该由程序员编写的运行时类型检查，通过声明式（Declarative）的方式让解释器执行罢了。

我认为引入类型系统，一方面是为了确保程序的正确性（强类型），另一方面是加速程序的运行（尽早确定操作符，而不是动态派发）。但从 Benchmark 的结果来看，如果不再解释器的层次上实现 Type Annotation 和 Type Checking，实际应用的前途不太大啊。

billy #8 2015年04月14日

那个 Rubype 在每个 method 下面都加那么一行，看着就醉了，还真不如直接写 Java。

就你的具体问题来说：

wft这个方法确实可以加一点说明，因为 float 非常规。但是，与其写成无意义的参数名wft(A, B)加说明，不如直接写成wft(foo_string, bar_float), 这样不用任何说明别人都能看懂。

关于process(id)，如果这个方法是你写的，而你估计有可能出现 id 为 string 的情况，你应该在方法的首行加一个保护， id = id.to_i。如果基本没有这个可能则不用麻烦。

如果这个方法是别人的，直接传送 Fixnum，无须顾虑。参数写了 id 就已经表明了作者的意图是接受 integer。如果不是，你可以去批评他。

需要登录后方可回复, 如果你还没有账号请注册新账号

新手问题 关于阅读 / 查看 「动态语言」源代码，这个问题怎么解决？