Page 214 - 《软件学报》2021年第7期

2132 Journal of Software 软件学报 Vol.32, No.7, July 2021

段代码(即处于 code 标签内)的帖子.基于这些帖子的标题和相关代码构建语料库.随后借助一种半监督分类方
法来进行数据清理,移除掉标题与代码不相关的数据.最终在他们共享的语料库内,共包含 66 015 对基于 C#的
代码-注释对和 32 337 对基于 SQL 的代码-注释对.
随后,Hu 等人共享了两个高质量语料库.(1) 在文献[76]中,Hu 等人构造了两个语料库.一个用于 API 序列总
结,另一个用于代码注释生成.这两个语料库均搜集自 Github.API 序列总结语料库包含了介于 2009 年~2014 年
之间的 Java 项目,并用于学习 API 知识.代码注释生成语料库考虑的项目来自 2015 年~2017 年.为了确保项目的
质量,他们仅选择了 star 数超过 20 的项目.最终,第 1 个语料库内共含有 340 922 对API 序列,注释,第 2 个语料
库内共含有 69 708 对API 序列,代码,注释.(2) 在文献[13]中,Hu 等人使用 Eclipse JDT compiler 将 Java 方法内
的代码解析成 AST,并从中抽取出 JavaDoc 注释.他们将不含有 JavaDoc 的方法移除掉.对于每一种方法,他们将
出现在 JavaDoc 中的第 1 个句子作为该方法的注释,因为一般来说,JavaDoc 的第 1 个句子主要用于描述方法的
功能.除此之外,他们也未考虑 setter 方法、getter 方法、构造方法和基于 JUnit 的测试方法,因为这些类型的方
法比较容易生成注释.最终他们搜集了 588 108 对Java 方法、注释.在数据集划分时,他们选择 80%的数据作为
训练集,10%的数据作为验证集,剩余 10%的数据作为测试集.在所搜集的语料库内,代码和注释平均包含的词素
数分别是 99.94 和 8.86.同时,他们也发现 95%的代码注释含有的词素数不超过 50,90%的方法含有的词素数不
超过 200.在训练时,他们使用通用词素NUM和STR分别代替 numerals 和 strings;使用特殊符号PAD来对短
序列进行填充,长序列被统一限制在 400 个词素.在模型训练的解码阶段,他们增加了特殊词素START和
EOS.其中,START表示编码序列的开始,而EOS表示编码序列的结束.注释的最大长度被限制到 30.同时,
AST 序列和注释的词汇表规模都被设置为 30 000.在 AST 序列中没有UNK词素,但对注释中出现的 OOV 词素,
他们统一将其替换成UNK词素.
Barone 等人 [81] 共享的语料库,主要搜集来自开源项目托管网站 Github 的项目,他们重点关注的是 Python
编程语言.该语料库共包含了 108 726 个代码-注释对,其中,代码和注释的词汇表规模分别为 50 400 和 31 350.
为了进行交叉验证,他们使用了 60%的数据作为训练集,20%的数据作为验证集,剩余 20%的数据作为测试集.
Jiang 等人 [46] 通过从 Github 中排名前 1 000 的项目内搜集代码变更与对应的提交信息来构建语料库.首先,
他们从提交消息中抽取第 1 个句子作为目标序列,因为一般来说,第 1 个句子是提交消息的总结.之后,将代码变
更和提交消息中的 commit id 和 issue id 移除掉,因为这些 ID 取值不但没有实际意义,还会扩大词汇表规模.接着,
他们移除了 merge 类型和 rollback 类型的代码变更,因为这两类代码变更涉及的代码修改量较大,并且过长的序
列也是基于深度学习的方法难以处理的.同样,他们也移除了规模超过 1M 的代码变更.然后,他们将代码变更序
列和注释序列长度超过 100 和 30 的相关数据移除掉,并使用 V-DO(verb-direct object)过滤器来进一步移除低质
量的代码变更.
不难看出,目前文献[13,46,81]共享的语料库是当前代码注释自动生成问题研究中使用次数较多的 3 个语
料库.但是通过分析已共享的代码注释自动生成语料库,不难发现,大部分语料库都是基于 Java 和 Python 来构建
的,基于这类编程语言的注释通常具有公认的文档标准,例如一般注释摘要位于注释的头部.而基于其他编程语
言(例如 C 或 C++)的代码注释,通常结构性较差,因此从这些无结构的代码注释中提取注释摘要具有一定的研
究挑战性.Eberhart 等人 [84] 提出一种基于众包的注释摘要提取方法.首先,他们雇佣了经验丰富的开发人员从
1 000 个针对 C 的代码注释中抽取出注释摘要.随后,基于 Amazon Mechanical Turk 众包平台从 120 000 个针对
C 的代码注释中抽取出注释摘要.这些注释摘要的质量稍差,但数量更多且搜集代价较低.之后,受自然语言处理
领域中关键短语检测的启发,他们提出了一种自动化方法,该方法基于来自众包平台的标记来训练模型,并利用
来自经验丰富的开发人员的标记来评估模型的性能.最终实验结果表明,他们提出的自动方法可以取得较好的
性能.

6 代码注释生成质量的评估方法

精确评估生成的代码注释质量仍然是一个开放性问题.相对于文本分类和机器翻译等自然语言处理的应