问自己:这段程序是做什么的?

红薯 发布于 2010/08/13 12:36
阅读 262
收藏 1

在SciPy 2010大会上,一位发言人给我们展示了几段简短的代码,并且问我们每段代码都是做什么用的。代码写的很明了,但没有提供上下文的注解。下面的就是这最后一段代码:

 

def what( x, n ):
    if n < 0:
        n = -n
        x = 1.0 / x
    z = 1.0
    while n > 0:
        if n % 2 == 1:
            z *= x
        x *= x
        n /= 2
    return z

这个测试是在这天快要结束时进行的,我有些累了。我说不出这段代码是干什么用的。可后来我发现自己处于很尴尬的境地,其实这段代码所实现的算法我是十分熟悉的。我曾经写过相同的代码,而且还写在了博客里。

 

这个事件使我改变了对“自我注解”程序的理解。没有上下文的提示,你很难理解一段代码是干什么用的,即使是很小一段。

有意义的变量名称和函数名能给理解程序带来很大帮助,但一句简单的注释带来的帮助更大。我们不需要那些冗余的注释,就像解释这行代码x = 1.0 / x 是取一个数的倒数,我们要的注释是能解释这段代码是来解决什么问题的。

这还有个例子,你认为这段代码是干什么的?

 

uint what()
{
    m_z = 36969 * (m_z & 65535) + (m_z >> 16);
    m_w = 18000 * (m_w & 65535) + (m_w >> 16);
    return (m_z << 16) + (m_w & 65535);
}

 

很明显这段代码是处理底层问题的 — 它只有一些操作 — 但我们完全不知道它是干什么的。

在继续往下读之前你最好尽力思考一下这段代码。如果你放弃了,那我告诉你,上面的第一段代码是来自这里的,第二段代码是来自这里的

在通常我们的面对面交流中,有很多的信息是来自口头表达之外的。我们通常会认为我们的语言表达是最重要的,但是我们的语调,面部表情,肢体语言等传递了更多的信息。程序源代码跟这些很相似,我们通常会在里面隐含着大量的其它信息。

假设你的同事Sam请你帮他审查一下他的代码。工作中发生这种情况一般你能得到大量的上下文语境帮助;它们并不是网上的某个随机的代码片段。更特殊 的是,你还对Sam所工作的项目有相当的了解。你知道Sam为什么希望你帮他看一下他的代码。也许他想炫耀一下他引以为豪的杰作,或者他希望你帮他找出一 个bug。你在看他的代码之前已经有了相当的了解。

但如果你是个接手人。Sam不幸被车撞了,你被要求在Sam出院之前维护他写的代码。你很可能会向他的同事抱怨,说他写的代码是如此的糟糕,但他的同事却不理解你为什么要这样说。他的同事会认为Sam的代码非常的清晰易懂。

再假设你是Sam接手人,而且在世界的另一端。你不能跟他的同事很好的交流,你只知道很少的上下文语境。在痛苦的折磨后,你把你修改的程序发回Sam的公司。你把你的程序注释的非常充分,但Sam的同事却抱怨你的代码乱极了,你并没把问题真正的解决。

共事共识比源代码注释更有价值。所以说替换一个程序员的代价是巨大的,即使是他走时留下的是注释很好的程序。

英文原文地址链接是http://www.johndcook.com/blog/2010/07/21/what-does-this-code-do/

加载中
返回顶部
顶部