年份：2020（The Journal of Systems & Software期刊）
论文Github网址：点击进入
背景：
?一个智能的代码注释器应该是能够首先根据一段给定的代码，找出应该注释的正确位置，然后为这段代码生成一段注释。
?检测出注释的正确位置是十分有意义的。之前有很多有关代码注释生成的研究是基于一个假设：就是哪部分需要注释是确定的。
?由于代码之间的复杂逻辑关系，识别出合理的注释位置也是一项具有挑战性的任务。
论文主要贡献：
?提出了一个叫CommtPst的模型。其能够有效地识别出代码段中的合理注释位置。采用了AST提取代码的语法信息，以及对代码做预处理后提取到了用于表示代码语义信息的文本元素。然后随机打乱整合每一句代码的语法和语义信息，利用word2vec将其向量化。最后就是?利用Bi-LSTM模型来建模代码语句之间的逻辑关系，以进一步识别出代码段中的注释位置。实验部分，通过和其他模型的对比以及一些对比实验，证明了论文提出的模型的有效性和可行性。
数据集：
?论文调查了10个Github上的大型开源软件项目（都是Java语言）。
?注释有两种类型：
?1.header comment
?2.internal comment
?由于header comment只出现于类或函数的声明之前，所以没必要识别预测它。所以论文只对internal header做识别预测。
?若函数里的代码行含有internal comment，则其会被标注成“commented”，反之为“uncommented”。
?当然，有一些不需要的internal comment我们要滤除。如这种
// if(obj.getName() == null)
?这种显然是开发者丢弃或用来测试的代码语句。
?还有一种就是由工具自动生成的注释：
// Auto-generated catch block
?然后这两种不需要的注释，论文结合AST以及一些基于关键词的方法将其滤除。
代码语法信息的提取：
?利用AST进行代码语法信息的提取（工具：Eclipse JDT）。最后每行代码都可提取得到它的syntax tokens。如下图：
代码语义信息的提取：
?代码语句中有些词会影响其代码的语义。所以制定了一些预处理规则对代码行进行预处理：
?1.将驼峰式变量命名切分，如变量名getFirstName，切分成get，First，Name。
?2.去停用词，如and，the等。（论文有对应停用词表网址查询）
?3.滤除单个的字母或数字
?4.为了减少整个语料库的词汇数量，采用了一个叫stem segmentation的技术（文章有提供对应论文）。因为英语中的动词有很多种时态，所以利用这个技术将其都转换成原始时态即可。
两种特征信息的融合以及量化：
?由于语法信息时由AST解析得出的syntax tokens，而语义信息则是通过预处理代码得到的文本元素。它们是两者不同方式表示的特征，难以直接将它们进行融合。
?对于这两种特征信息的融合，论文是这样做的：
?每一个代码语句，随机将syntax tokens和对应的文本元素打乱，将打乱结果作为一个整体，加进语料库。如下图：
?接下来就是用word2vec模型（skip-gram形式）进行训练，然后对每条数据的元素（即上述打乱的结果）进行向量化，每个向量都是固定的维度。然后将一条数据的所有向量取平均得到这句代码语句的向量。这样这个向量即包含了语法结构信息，也包含了代码语义信息。
Bi-LSTM模型的引入：
?Bi-LSTM模型不仅可以有效保留序列的长期依赖关系，而且能够双向地学习代码上下文周围信息的关系。Bi-LSTM原理就不做解释了，它是NLP领域较为常见的模型。如下图：
实验配置：
?因为函数越短，它可能包含的注释越少，论文经过统计，最后滤除了代码行少于5行的函数。并增加了2000份完全没有注释的函数。所以最后一共有16942份函数数据。按大约8:1:1的比例切分成训练集，验证集，测试集。
?因为不同函数长度不同，且有95%左右代码少于50行，所以将Bi-LSTM的time steps设置为50以适应不同输入。大于50的切除，小于50则用0向量补充。
其他一些模型超参数的设置，请看论文。
实验的评估指标：
1.Precision
2.Recall
3.F-MEASURE
实验部分：
?实验主要围绕以下4个问题展开：
? RQ1: What is the accuracy of CommtPst in predicting commenting positions?
? RQ2: What are the impacts of structural and semantic features on the accuracy?
? RQ3: Does the method size (i.e., code amount) affect the accuracy of CommtPst?
? RQ4: Does the number of comments per method affect the accuracy of CommtPst?
RQ1: What is the accuracy of CommtPst in predicting commenting positions?
?在之前，论文的作者也提出了一个用传统机器学习预测注释位置的方法，交“CommentSuggester”，对比结果如下：
?下面是采用不同DL模型和词向量表示模型结合的各种情况对比：
?整体来看Bi-LSTM模型和word2vec模型的结合表现更为出色。
?下面是对比了5种随机种子生成的数据集对模型性能的影响，额。。影响不大。
RQ2: What are the impacts of structural and semantic features on the accuracy?
?下面对比了分别单独采用语法、语义信息，两者信息都采用的情况，明显两者信息都采用时更牛。所以这也证明了上述采用的两者信息的融合方法的有效性，它能够使模型从代码中学习更多的注释模式。
?同时，论文对比了对代码行的所有元素的向量取平均、求和、取最大值的方法，结果如下。明显取平均更牛呗。
RQ3: Does the method size (i.e., code amount) affect the accuracy of CommtPst?
?因为代码行数在5-50的函数占了94%，所以这一部分实验只利用这一范围内的数据。
?这一部分是评估函数的行数对模型性能有无影响。结果如下。额，有点波动，不过准确率还是较为稳定。（？是吗，反正论文这么说，咋也不敢多问）
RQ4: Does the number of comments per method affect the accuracy of CommtPst?
?由于拥有小于等于4个注释的函数占比81%。所以这一部分实验只利用这一部分数据。
?这一部分对比拥有不同数量注释的函数对模型性能影响。结果如下。额。。影响也不是很大。
讨论：FN是真的FN吗？
?FN即假阴性，为验证假阴性样本是否真的不需要注释。论文请了5个资深程序员验证，最后得出了：32%的FN样本应该被注释。即这32%的FN应该是TP。
资深程序员认为主要有两个主要的原因，这些FN样本应该被加注释：
1.代码逻辑复杂
2.糟糕的代码命名风格
?所以修正评估指标的公式，如下：
?重新计算模型的实验指标结果如下：
讨论：语法和语义信息是否要随机打乱整合？
?实验对比结果如下。明显随机打乱效果更好咯。。论文将其归因于：随机打乱语法和语义信息进行融合能够使word embedding更有效地挖掘这两种信息的整体关系。牛哦~
相关工作：
?主要分为两部分（具体看论文里介绍啦）：
1.Source code commenting practices
包含注释质量的评估和代码注释生成方面的研究。
2.Applying deep learning to source code analysis
?以上相关工作中有很多方法，很多都结合了DL，比如有些结合AST和CNN一起的呀，有些用RNN编码解码器的呀，等等。论文作者从以上相关工作中获得了许多启发，所以提出了论文中的方法。
对有效性的威胁
?1.实验指标的选取。因为论文的问题实际上可以看成是一个二分类问题（标注为注释或未注释）。所以采用这几个实验指标是较为合适的，威胁性不大。
?2.模型泛化性的威胁。由于数据集都是Java代码，当用到别的代码语言结果可能不太好。所以未来研究中将会分析更多其他代码语言编写的函数去减轻这个威胁。
?3.注释的质量问题。因为数据集中不可避免的有一些低质量的注释没有完全去除，所以在未来研究中将会进一步调查研究这些注释的质量，更有效地将其过滤。
未来方向：
?完善代码注释位置预测模型，建立一个更为智能的注释模型，能够自预测出合理的代码注释位置，然后生成对应代码段的注释。