基于机器学习的方法名称推荐

高质量的方法名称对于程序的可读性和可维护性至关重要。但是，构造简洁而一致的方法名称通常具有挑战性，对于经验不足的开发人员而言尤其如此。为此，最近已利用先进的机器学习技术为给定的方法主体/实现自动推荐方法名称。最近的大规模评估也表明这种方法是准确的。但是，对于这种方法失效的情况和原因目前仍不是很了解。为了弄清最新技术以及成功/失败的原因，在本文中，我们对最新的方法 code2vec 进行了实证研究。我们在贴合实际的新数据集上评估 code2vec。我们的评估结果表明，尽管切换到新的数据集不会显着影响性能，但更贴合实际的设置会显着降低 code2vec 的性能。对成功推荐的方法名称的进一步分析还发现以下发现：1）大约一半（48.3％）的被采纳方法名称建议是在 getter/setter 方法上达到的； 2）被成功推荐的方法名称很大一部分是可以通过从给定的内容中复制得到的（19.2％）。为了进一步验证其有用性，我们要求开发人员手动的对命名他们开发的方法名称的难度进行评分，然后将 Code2vec 应用于此类手动评分过的方法，以评估其有效性。我们的评估结果表明，在真正需要 code2vec 时，它很少起作用。最后，为了直观地揭示现有技术水平并调查设计简单明了的替代方法的可能性，我们提出了一种基于启发式来推荐方法名称的技术。在大规模数据集上的评估结果表明，这种基于启发式的简单方法明显优于基于机器学习的最新方法，其准确性和召回率分别提高了 65.25％和 22.45％。比较表明，基于机器学习的方法名称推荐可能还有很长的路要走。

1.介绍

标识符被广泛用于标识唯一的软件实体。 根据最近的研究表明，就字符而言，标识符大约占源代码的 70％。一个结构良好的标识符不仅要遵循特定于语言的命名约定，而且要传达其关联软件实体的意图和责任。 因此，高质量的标识符对源代码的可读性有重要影响。

方法名称是一种特殊的标识符，用于标识方法。方法是聚集行为的最小命名单位，并且是抽象的基石。此类方法的可读性对于理解程序的功能以及不同单元（方法）之间的交互作用至关重要。但是，构造高质量的方法名称通常具有挑战性，特别是对于没有经验的开发人员而言。

为了直观地说明现有技术，并调查设计简单而有效的方法的可能性，我们提出了一种基于启发式的方法，为给定的方法主体推荐方法名称（称为 HeMa）。 从本质上讲，这是一系列简单的启发式方法，因此很容易遵循。 评估结果表明，它明显优于最新的基于 ML 的 code2vec。

本文做出了以下贡献：

1. 首先，对基于 ML 的方法名称推荐中的最新方法进行全面评估和深入分析。分析不仅揭示了最新技术，而且还发现了该方法在何处以及为何起作用或不起作用。
2. 其次，实现了一种推荐方法名称的简单明了的方法。 在评估中，它明显优于最新的基于 ML 的复杂方法，这表明基于 ML 的方法可能还有很长的路要走。

本文的其余部分结构如下。 第二节介绍相关工作。 第三节介绍了实证设置，第四节介绍了结果和分析。 第五部分提出了一种基于启发式的方法。 第六节讨论相关问题，第七节介绍结论和未来的工作。

2. 实验设置

本部分指定了实验的设置，即为评估选择的方法，预期要回答的研究问题以及用于定量评估方法性能的指标。

A.评估方法

为了评估基于 ML 的方法名称推荐的状态，我们选择 code2vec 进行评估。 选择 code2vec 的原因如下。 首先，它代表了该领域的最新技术。 code2vec 是最近在 POPL 2019 上提出的，并且被证明比其他方法更准确。其次，其实现的源代码是公开可用的，这极大地促进了评估。它还方便其他研究人员复制实验。我们在 GitHub 上公开提供了评估的复制包，以方便第三方复制和进一步调查。

B.研究问题

该实验调查以下研究问题：

RQ1：除了 code2vec 作者进行的原始评估所采用的数据集以外，code2vec 在其他数据集上的工作情况如何？

RQ2：code2vec 在更实际的设置下的性能如何？

RQ3：当给定的方法主体不包含方法名称标记时，code2vec 是否可以正确生成方法名称？

RQ4：code2vec 在哪里以及为什么起作用？

RQ5：code2vec 在哪里以及为什么会失败？

RQ6：code2vec 对开发人员有用吗？ 对于难以手动命名的方法，code2vec 正确建议的频率如何？

研究问题 RQ1 验证了替换评估数据时 code2vec 是否保持高度准确。 code2vec 最初是在一个大数据集（简称为原始数据集）上进行评估的。此外，我们还使用另一个公共可用的数据集（简称为新数据集），该数据集由 GitHub 上的 1000 个顶级 Java 项目组成。 回答这个问题可能会揭示 code2vec 的一般性。

研究问题 RQ2 验证了 code2vec 对实证设置的敏感性。在原数据集中进行的原始评估是基于文件的，即将来自应用程序的 Java 文件打包，并随机分为三组（训练，验证和测试集）。结果，在为项目推荐方法名称时，code2vec 可能会利用同一项目中的大量文件。我们称这种验证为基于文件的验证。尽管基于文件的验证是合理的，但开发人员经常从头开始创建新项目，因此他们没有来自当前项目的足够数据来训练方法名称推荐模型。基于项目的验证适合这种情况。它还将开发人员从现场培训中解放出来，这要求对底层学习模型有深入的了解。在此设置（基于项目的验证）中，我们使用开源主题应用程序集对在线下对 code2vec 进行了预训练，并且未利用测试项目中的源代码进行培训。基于项目的验证的主要进步在于，在开发人员实际利用此类模型进行方法名称推荐之前，要一劳永逸地进行耗时和资源消耗的模型训练。第三个验证设置是基于项目的非覆盖验证。基于项目的非覆盖验证和基于项目的验证之间的唯一区别是，覆盖方法被前者模式排除，但被后者包含。尽管原始数据集中的原始评估排除了构造函数，因为开发人员不太可能知道构造函数的名称，但他们并未排除与构造函数非常相似的重写方法。覆盖方法与其覆盖的方法具有相同的名称，因此开发人员在命名此类方法时不太可能需要帮助。

当给定的方法主体不包含方法名称标记时，研究问题 RQ3 将研究 code2vec 的性能。 回答研究问题 RQ3 可能会揭示 code2vec 可以在多大程度上正确地创建（而不是复制）方法名称。

研究问题 RQ4 和 RQ5 研究了 code2vec 的优缺点。 code2vec 可能在一种方法类别上运行良好，但在另一种方法上运行不良。 回答这两个研究问题可能会揭示 code2vec 在哪里成功/失败以及成功/失败的理由。

研究问题 RQ6 与 code2vec 的用途有关。 有用性取决于推荐的准确性和方法名称构造的难度。 如果在要求推荐困难的方法名称时（即在确实需要时），code2vec 经常失败，那么这对开发人员将毫无用处。 为此，我们手动对命名方法的难度进行评分，然后根据评分评估该方法的有效性。 回答研究问题 RQ6 有助于揭示 code2vec 在真正需要时的有效性。

3.结果分析

A. RQ1：不同数据集上的性能对比

为了解决研究问题 RQ1，我们在新数据集及其在论文中使用的原始数据集上评估了 code2vec。为了与论文中的评估保持一致，我们从每个数据集中随机选择 50,000 个 Java 文件作为测试集，并从中选择另外 50,000 个作为验证集。 其他被用作训练集。

评估结果列于表 I。第一列显示了评估所采用的数据集。 第二列介绍了涉及的数据集的大小。 第三至第五列显示了 code2vec 的性能（准确率/召回率），以定量地显示正确的方法名称出现在前 k 个推荐列表中的频率。最后一栏显示了 code2vec 的均值倒数排名。 值得注意的是，对于 code2vec，其召回率始终与准确率相同。

从表中，我们得出以下结论：

1. 首先，code2vec 在推荐方法名称方面是准确的。 前 1 个建议通常是正确的（原始数据集的概率为 49.89％，新数据集的概率为 43.87％）。 它有很大的机会（在原始数据集上占 58.41％，在新数据集上占 51.33％）在其前 10 个推荐列表中显示正确的方法名称。 高 MRR（分别为 52.96％和 46.51％）也表明正确的名称通常排在首位。

2.其次，切换数据集不会导致性能显着降低。 尽管准确率/召回率略有降低（例如，从第 1 级的 49.89％降低到 43.87％），但降低的主要原因是新数据集的大小：新数据集中的方法数量仅为原始数据集的 28.6％。

我们从前面的分析得出结论，code2vec 总体上是准确的，并且切换到新的大规模数据集并不会导致 code2vec 的性能显着降低。

B. RQ2：实证设置会导致性能降低

为了解决研究问题 RQ2，我们在具有不同设置的新数据集上评估 code2vec，即基于文件的验证，基于项目的验证和基于项目的非覆盖验证。 基于文件的验证将数据集分为文件级别的训练，验证和测试集，而其他两个验证则在项目级别工作。 基于项目的验证与基于项目的非覆盖验证之间的唯一区别是，重写方法被后者排除，但被前者包括。

图 1 显示了不同设置下的评估结果。从图上，我们得出以下观察结果：

1.将评估设置从基于文件的验证转换为基于项目的验证会显着降低性能。 精确度/召回率在 rank 1 处显着降低 46.84％=（43.87％-23.32％）/ 43.87％，在 rank 5 处为 41.98％=（49.90％-28.95％）/ 49.90％，在 rank 10 处为 40.42％=（51.33％- 30.58％）/ 51.33％.

1. 其次，排除重写方法会进一步降低 code2vec 的性能。 值得注意的是，重写方法很普遍，占数据集中方法的 30％= 1,147,980 / 3,826,986。 如果排除此类方法，则精确度/召回率将在 rank 1 处降低 12.14％=（23.32％-20.49％）/ 23.32％，在 rank 5 处降低 13.96％=（28.95％-24.91％）/ 28.95％，而在 rank 10 处降低 14.09％=（30.58％- 26.27％）/ 30.58％。

3.总体来说，code2vec 在不同的设置下都能很好地工作。 无论设置如何变化，其准确度/召回率都保持大于 20％，这表明在超过五分之一的情况下，code2vec 成功推断出确切的方法名称。 高的 MRR（基于文件的验证，基于项目的验证和基于项目的非覆盖验证分别为 46.51％，25.76％和 22.43％）也表明 code2vec 很有前景。

从前面的分析我们可以得出结论，在更实际的设置下，code2vec 的性能将显着降低。 但是，它的整体性能还是很有前景的。

C.RQ3：方法名称

为了解决研究问题 RQ3，我们评估了 code2vec 在分别生成可见和不可见方法名称标记时的性能。 对于新数据集中的每个方法名称，我们根据 Camel-Case 命名约定将其拆分为标记。 如果 t 出现在由 mn 命名的主体中（不区分大小写），则来自方法名称 mn 的标记 t 是可见的标记。 否则，这是一个看不见的标记。 我们评估了在基于项目的非覆盖验证期间，code2vec 能够成功推荐可见/不可见方法名称标记的频率。

评价结果列于表 II。 第一列显示方法名称标记的类型：不可见的标记和可见的标记。 第二列显示了测试集中可见/不可见方法名称标记的总数。 第三列显示正确推荐的可见/不可见方法名称标记的数量。 当且仅当为 mn 方法主体推荐的名称包含标记 t 时， mn 中的标记 t 才会正确地被建议作为方法名称。 第四列显示正确建议使用/看不见的方法名称标记的几率。 通过将正确推荐的可见/不可见方法名称标记的数量除以总数来计算几率。

从表中，我们得出以下结论：

1.很大一部分方法名称标记（39.86％= 385,225 /（385,225 + 581,237））是不可见的，即它们不会出现在输入中（方法主体）。 因此，这会对高度依赖复制机制从输入中选择令牌的基于 ML 的方法有较大限制。

1. code2vec 在推荐不可见的方法名称标记时效果很好。 它成功生成了 22.07％的不可见的标记。 它在生成不可见的方法名称标记方面的性能甚至可以与可见标记上的性能相媲美（26.29％）。

code2vec 可以生成看不见的方法名称标记，因为它不会从其输入（即方法主体）中选择（复制）标记。 相比之下，它提取方法的特征（即连接方法主体中的 AST 的节点的路径），并将这些特征与方法名称相关联。 结果，如果给定的方法主体（mb1）与训练集中的另一个方法主体（mb2）共享相同或高度相似的功能，则即使 Namemb2 的标记没有在 mb1 中出现过 code2vec 可能也会为 mb1 推荐方法名称 Namemb2。

通过前面几段的分析，我们得出结论，code2vec 在生成看不见的方法名称标记时效果很好。

D. RQ4：code2vec 在何处以及为何起作用

为了研究 code2vec 在何处以及为什么起作用，我们在基于项目的非覆盖验证期间手动分析了它在什么情况下起作用。 值得注意的是，code2vec 在大量（61,906）种方法上都取得了成功，因此，即使不是不可能，手动分析所有这些方法也具有挑战性。 为此，我们随机抽取了千种方法进行手动分析。 基于手动分析，我们得到了以下结论：

1.大多数（48.3％= 483 / 1,000）被接受的建议名称用于 getter / setter 方法。

1. 通常可以从相应的方法主体中复制正确的方法名称（机会为 19.2％）。 在本文的其余部分，我们将此类方法称为包含名称的方法。

从前面的分析中我们可以得出结论，code2vec 在 getter / setter 方法和委托上运行良好。成功的理由是，此类方法的 AST 具有相同的结构。

E. RQ5：code2vec 在何处以及为何失败

为了研究 code2vec 在何处以及为何失败，我们进行了另一次手动分析。 唯一的区别是，这里我们在基于项目的非覆盖验证期间分析了 1000 个失败案例，而非成功案例。

基于手动分析，我们找出导致失败的以下主要原因。 首先，不在词汇表中的方法名称是失败的主要原因。 当且仅当训练集中的任何方法都不是以其命名的，则该方法名称被称为不在词汇表中的方法。 值得注意的是，code2vec 通过收集训练集中的所有唯一方法名称来构建方法名称的词汇表，并从该词汇表中选择一个名称作为给定方法主体的推荐。 因此，如果最佳方法名称未包含在词汇表中，则 code2vec 没有机会生成它。 这种方法很常见，占测试集中方法的 52％= 157,128 / 302,200。由于这个原因，code2vec 经常失败。 通过组合标记使用开放的词汇表或标记方法名称可能有助于进一步提高性能。

失败的第二个原因是被利用的方法功能通常不足以推断方法名称。 清单 4 给出了一个典型示例。 除数据类型（TIncrement 与 ReportAttributes）外，deepCopy 和 build 的方法主体几乎相同。 因此，code2vec 将其 AST 路径用作方法功能也非常相似。 结果，code2vec 为它们推荐了相同的名称。

失败的第三个原因是测试集中的方法名称不正确。在评估过程中，将所有推荐名称与测试方法关联的原始名称进行比较，即，如果推荐名称与原始名称不同，则 code2vec 失败。但是，建议的名称可能会比原始名称更好。在这种情况下，code2vec 失败，我们称这种情况为假阴性。

F. RQ6：开发人员的有用性有限

为了回答研究问题 RQ6，我们研究了在非常需要 code2vec 时其有效性。 调查如下：

1. 我们邀请六个参与商业项目的开发人员进行评估。 这个商业项目最近由 IT 行业的巨头发布，以进行大规模的软件重构。
2. 对于每个参与者，我们随机选择自己开发的一百种方法。
3. 我们要求所有参与者在抽样方法时对命名难度进行评分。 值得注意的是，参与者没有为其他开发人员开发的方法评分，因此他们每个人都为一百种方法评分。 分数介于 1 到 5 之间，其中 1 代表最低难度，而 5 代表最高难度。
4. 我们将基于项目的非覆盖验证的 code2vec 应用于计分方法，并针对人工构建的名称验证建议。

评价结果列于表 III。第一列显示命名方法的难度评分。第二列介绍了具体方法的数量。第三列介绍了给定方法在 rank 1 级 code2vec 的精度/调用率。

从表中，我们得出以下结论：

1. 即使对于这种方法的作者，也很难说出很大比例的方法。 我们注意到，在 600 种方法中，有 13 种极其难命名，有 50 种难命名。 总共，有经验的开发人员很难对 10.5％=（13 + 50）/ 600 的方法进行命名。
2. code2vec 的整体精度/召回率（19.50％）与之前的大规模数据集相当，后者在 rank 1 的精度为 20.49％。 它表明，有关开源应用程序的结论也可能适用于商业封闭源应用程序。
3. code2vec 在非常易于命名的方法上运行良好，因此精度高达 34.84％。
4. code2vec 在极难推荐名称的方法上很少成功，在这种情况下，强烈需要有关方法名称的建议。 在所有 13 种极其困难的命名方法中，以及在 50 种难以命名的方法中，有 49 种都失败了。 总体而言，该方法的精度显着降低至 1.6％。 我们还注意到，其准确率随着难度分数的增加而显着降低。

根据上一段中的分析，我们得出结论，在强烈需要 code2vec 的情况下，code2vec 很少成功。

6. 结论与未来工作

最近的研究在机器学习技术方面取得了重大进步。结果，许多最终的先进机器学习技术被用于解决软件工程任务，例如代码完成和方法名称推荐。尽管已证明基于机器学习的方法在生成方法名称方面是准确的，但是由于各种原因（例如任意实证设置），现有评估无法完全实现其真实性能。这样的评估无法揭示现有方法在何处以及为何起作用。为此，在本文中，我们对具有更实际设置的最新方法名称推荐方法 code2vec 进行了实证研究。我们的评估结果表明，code2vec 应该得到重大改进。为了直观地揭示现有技术水平并调查设计简单明了的替代方法的可能性，我们还提出了一种基于启发式的方法，根据给定的方法主体来推荐方法名称。我们的评估结果表明，它的性能明显优于 code2vec，并将准确性和召回率分别提高了 65.25％和 22.45％。

实证研究的意义是多重的。 首先，实证设置对于实证研究至关重要，而不正确的设置可能会严重扭曲基于经验研究得出的结论。 其次，不应仅通过其性能（例如精度和召回率）来评估自动软件工程工具的有用性。 第三，先进和复杂的方法不一定比简单直接的方法更好。 最后，基于机器学习的方法名称推荐可能无法达到预期效果。 通过更严格的设置，基于深度学习的 code2vec 经常失败。 但是，在本文中，我们仅凭经验评估 code2vec，在我们的设置中，其他基于机器学习的方法可能优于 code2vec。 将来，研究这个问题应该会很有趣。