摘要：高质量的方法名称对于法式的可读性和可维护性至关重要。可是，结构简练而一致的方法名称通常具有挑战性，对于履历不足的开发人员而言尤其如此。为此，最近已使用先进的机械学习技术为给定的方法主体/实现自动推荐方法名称。
最近的大规模评估也讲明这种方法是准确的。可是，对于这种方法失效的情况和原因现在仍不是很相识。为了弄清最新技术以及乐成/失败的原因，在本文中，我们对最新的方法 code2vec 举行了实证研究。我们在贴合实际的新数据集上评估 code2vec。
我们的评估效果讲明，只管切换到新的数据集不会显着影响性能，但更贴合实际的设置会显着降低 code2vec 的性能。对乐成推荐的方法名称的进一步分析还发现以下发现：1）约莫一半（48.3％）的被采取方法名称建议是在 getter/setter 方法上到达的； 2）被乐成推荐的方法名称很大一部门是可以通过从给定的内容中复制获得的（19.2％）。为了进一步验证其有用性，我们要求开发人员手动的对命名他们开发的方法名称的难度举行评分，然后将 Code2vec 应用于此类手动评分过的方法，以评估其有效性。我们的评估效果讲明，在真正需要 code2vec 时，它很少起作用。
最后，为了直观地展现现有技术水平并观察设计简朴明晰的替代方法的可能性，我们提出了一种基于启发式来推荐方法名称的技术。在大规模数据集上的评估效果讲明，这种基于启发式的简朴方法显着优于基于机械学习的最新方法，其准确性和召回率划分提高了 65.25％和 22.45％。比力讲明，基于机械学习的方法名称推荐可能另有很长的路要走。1.先容标识符被广泛用于标识唯一的软件实体。
凭据最近的研究讲明，就字符而言，标识符约莫占源代码的 70％。一个结构良好的标识符不仅要遵循特定于语言的命名约定，而且要转达其关联软件实体的意图和责任。
因此，高质量的标识符对源代码的可读性有重要影响。方法名称是一种特殊的标识符，用于标识方法。
方法是聚集行为的最小命名单元，而且是抽象的基石。此类方法的可读性对于明白法式的功效以及差别单元（方法）之间的交互作用至关重要。可是，结构高质量的方法名称通常具有挑战性，特别是对于没有履历的开发人员而言。
为了直观地说明现有技术，并观察设计简朴而有效的方法的可能性，我们提出了一种基于启发式的方法，为给定的方法主体推荐方法名称（称为 HeMa）。从本质上讲，这是一系列简朴的启发式方法，因此很容易遵循。评估效果讲明，它显着优于最新的基于 ML 的 code2vec。本文做出了以下孝敬：首先，对基于 ML 的方法名称推荐中的最新方法举行全面评估和深入分析。
分析不仅展现了最新技术，而且还发现了该方法在那边以及为何起作用或不起作用。其次，实现了一种推荐方法名称的简朴明晰的方法。在评估中，它显着优于最新的基于 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，其召回率始终与准确率相同。从表中，我们得出以下结论：首先，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％.其次，清除重写方法会进一步降低 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 的方法有较大限制。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 方法。通常可以从相应的方法主体中复制正确的方法名称（时机为 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 时其有效性。观察如下：我们邀请六个到场商业项目的开发人员举行评估。这个商业项目最近由 IT 行业的巨头公布，以举行大规模的软件重构。
对于每个到场者，我们随机选择自己开发的一百种方法。我们要求所有到场者在抽样方法时对命名难度举行评分。值得注意的是，到场者没有为其他开发人员开发的方法评分，因此他们每小我私家都为一百种方法评分。分数介于 1 到 5 之间，其中 1 代表最低难度，而 5 代表最高难度。
我们将基于项目的非笼罩验证的 code2vec 应用于计分方法，并针对人工构建的名称验证建议。评价效果列于表 III。
第一列显示命名方法的难度评分。第二列先容了详细方法的数量。第三列先容了给定方法在 rank 1 级 code2vec 的精度/挪用率。从表中，我们得出以下结论：纵然对于这种方法的作者，也很难说出很大比例的方法。
我们注意到，在 600 种方法中，有 13 种极其难命名，有 50 种难命名。总共，有履历的开发人员很难对 10.5％=（13 + 50）/ 600 的方法举行命名。code2vec 的整体精度/召回率（19.50％）与之前的大规模数据集相当，后者在 rank 1 的精度为 20.49％。
它讲明，有关开源应用法式的结论也可能适用于商业关闭源应用法式。code2vec 在很是易于命名的方法上运行良好，因此精度高达 34.84％。
code2vec 在极难推荐名称的方法上很少乐成，在这种情况下，强烈需要有关方法名称的建议。在所有 13 种极其难题的命名方法中，以及在 50 种难以命名的方法中，有 49 种都失败了。总体而言，该方法的精度显着降低至 1.6％。
我们还注意到，其准确率随着难度分数的增加而显着降低。凭据上一段中的分析，我们得出结论，在强烈需要 code2vec 的情况下，code2vec 很少乐成。
6. 结论与未来事情最近的研究在机械学习技术方面取得了重大进步。效果，许多最终的先进机械学习技术被用于解决软件工程任务，例如代码完成和方法名称推荐。
只管已证明基于机械学习的方法在生成方法名称方面是准确的，可是由于种种原因（例如任意实证设置），现有评估无法完全实现其真实性能。这样的评估无法展现现有方法在那边以及为何起作用。为此，在本文中，我们对具有更实际设置的最新方法名称推荐方法 code2vec 举行了实证研究。我们的评估效果讲明，code2vec 应该获得重大革新。
为了直观地展现现有技术水平并观察设计简朴明晰的替代方法的可能性，我们还提出了一种基于启发式的方法，凭据给定的方法主体来推荐方法名称。我们的评估效果讲明，它的性能显着优于 code2vec，并将准确性和召回率划分提高了 65.25％和 22.45％。
实证研究的意义是多重的。首先，实证设置对于实证研究至关重要，而不正确的设置可能会严重扭曲基于履历研究得出的结论。
其次，不应仅通过其性能（例如精度和召回率）来评估自动软件工程工具的有用性。第三，先进和庞大的方法纷歧定比简朴直接的方法更好。最后，基于机械学习的方法名称推荐可能无法到达预期效果。通过更严格的设置，基于深度学习的 code2vec 经常失败。
可是，在本文中，我们仅凭履历评估 code2vec，在我们的设置中，其他基于机械学习的方法可能优于 code2vec。未来，研究这个问题应该会很有趣。
致谢本文由南京大学软件学院 2020 级博士生虞圣呈翻译转述。
本文关键词：基于,机械,学习,的,方法,澳门人威尼斯官方网站,名称,推荐,摘要
本文来源：澳门人威尼斯官方网站-www.yzydc.com
