Predicting Usefulness of Code Review Comments using Textual Features and Developer Experience
虽然同行代码评审在商业和开源开发中被广泛采用，但现有的研究表明，这种代码评审通常包含大量无用的评审评论。不幸的是，到目前为止，还没有工具或技术可以提供自动支持，以改善这些无用的评论。在本文中，我们首先报告了一个有用和无用的评论之间的比较研究，我们对比他们之间的文本特征，和审稿人的经验。然后，根据研究结果，我们开发RevHelper，一个预测模型，可以帮助开发人员提高他们的代码审查意见，通过自动预测其有用性在审查提交。使用1，116条评论进行的比较研究表明，有用的评论与更改的代码共享更多的词汇，包含相关代码元素等突出项目，并且他们的评论者通常更有经验。使用1,482条评论的实验表明，我们的模型可以预测评论有用性，预测准确率为66%，这是很有前途的。使用案例研究的基线模型的三个变体的比较验证了我们的实证研究结果，并证明了我们的模型的潜力。
2018-07-12 cs.SE
What Types of Code Review Comments Do Developers Most Frequently Resolve?
The University of Melbourne（墨尔本大学）；Atlassian；Monash University（蒙纳士大学）
本研究利用LLM作为评判者分类评审评论，发现LLM与人类评审者各有优劣，且可读性、缺陷和维护性相关评论的解决率高于设计类评论，表明多数LLM生成评论具有可执行性。
2025-10-06 cs.SE
Automating the Removal of Obsolete TODO Comments
TODO注释被软件开发人员广泛用于描述他们在软件开发期间的未决任务。然而，在执行任务后，开发人员有时会忽略或忘记删除TODO注释，导致TODO注释过时。这些过时的TODO注释会使开发团队感到困惑，并可能导致将来引入错误，从而降低软件的质量和可维护性。在这项工作中，我们提出了一种新的模型，名为TDCleaner（TODO注释清洁），以确定过时的TODO评论在软件项目。TDCleaner可以帮助开发人员及时检查TODO注释状态，避免留下过时的TODO注释。我们的方法有两个主要阶段：离线学习和在线预测。在离线学习过程中，我们首先自动建立<code_change，todo_comment，commit_msg>训练样本，并利用三个神经编码器分别捕获TODO注释，代码更改和提交消息的语义特征。然后，TDCleaner会自动学习不同编码器之间的相关性和相互作用，以估计TODO注释的最终状态。对于在线预测，我们通过利用离线训练模型来判断TODO评论过时的可能性来检查TODO评论的状态。我们通过从前10，000个Python和Java Github存储库中收集TODO评论来构建数据集，并在其上评估TDCleaner。大量的实验结果表明，我们的模型在一组基准测试的有前途的性能。我们还对真实世界的软件项目进行了野外评估，我们向Github开发人员报告了TDCleaner识别的18条过时的TODO注释，…
2021-08-12 cs.SE
Are your comments outdated? Towards automatically detecting code-comment consistency
本文提出基于学习的 CoCC 方法，通过提取代码与注释变更前后特征及其关系来自动检测过时注释，精确率超过90%，并验证了跨语言适用性和实际项目有效性。
2024-03-01 cs.SE
Do Comments follow Commenting Conventions? A Case Study in Java and Python
该研究分析Java和Python注释规范及开发者实践，发现规范偏重内容且覆盖不足，实际注释行为与指南存在明显不匹配，并为质量检查工具改进提供方向。
2021-08-27 cs.SE
Where do developers admit their security-related concerns?
本研究针对开发者安全顾虑记录分散易过时的问题，通过分析4个工业级开源项目的2559个文档实例，明确了开发者偏好的记录渠道及问题搁置规律，并开发了提醒流水线以提升安全意识。
2024-05-17 cs.SE
Comments or Issues: Where to Document Technical Debt?
本文调查了190个GitHub项目中74K条SATD-C和20K条SATD-I实例的作者，探究开发者选择用注释或议题记录技术债务的动因，并提出了13条指南以辅助决策。
2024-08-27 cs.SE
ComFormer: Code Comment Generation via Transformer and Fusion Method-based Hybrid Code Representation
由于缺乏编程经验，开发人员经常编写低质量的代码注释，这会降低开发人员对程序的理解效率。因此，开发人员希望能够开发代码注释生成工具来说明代码的功能和目的。最近，研究人员主要将此问题建模为神经机器翻译问题，并倾向于使用基于深度学习的方法。在这项研究中，我们提出了一种新的方法ComFormer的基础上Transformer和融合方法为基础的混合代码表示。此外，为了缓解OOV（out-of-vocabulary）问题和加快模型训练，我们进一步使用Byte-BPE算法来分割标识符和Sim_SBT方法来执行AST训练。我们将ComFormer与来自代码注释生成和神经机器翻译域的七个最先进的基线进行比较。比较结果显示了ComFormer在三个性能指标方面的竞争力。此外，我们进行了一项人类研究，以验证ComFormer可以生成高质量的评论。
2021-07-08 cs.SE
An Empirical Study on Code Comment Completion
代码注释在程序理解活动中起着重要的作用。然而，源代码并不总是文档化的，代码和注释并不总是共同发展的。为了解决这些问题，研究人员提出了自动生成注释的技术，这些注释记录了手头的给定代码。该领域的最新工作应用了深度学习（DL）技术来支持这样的任务。尽管取得了进展，这些方法的实证评估表明，他们仍然远远没有一个性能水平，使他们有价值的开发人员。我们解决了一个更简单的相关问题：代码注释完成。我们不是从头开始为给定的代码生成注释，而是研究最先进的技术可以在多大程度上帮助开发人员更快地编写注释。我们提出了一个大规模的研究，我们经验性地评估如何一个简单的n-gram模型和最近提出的文本到文本传输Transformer（T5）架构可以执行自动完成代码注释的开发人员键入。所取得的结果显示了T5模型的优越性，尽管n-gram模型是一个有竞争力的解决方案。
2021-07-22 cs.SE
RepliComment: Identifying Clones in Code Comments
代码注释是记录实现和促进程序理解的主要手段。因此，它们的质量应该是改进程序维护的主要关注点。虽然很多工作都致力于检测不良气味，如代码中的克隆，但很少有工作集中在注释上。在本文中，我们提出了我们的解决方案来检测开发人员应该修复的评论中的克隆。<$Comment可以自动分析Java项目并报告注释中的复制粘贴错误实例，并可以向开发人员指出应该修复哪些注释。此外，当克隆是写得不好的评论的迹象时，它可以报告。开发人员也应该修复这些实例，以提高代码文档的质量。我们对10个著名的开源Java项目进行了评估，发现了超过11000个注释克隆实例，其中超过1,300个是潜在的关键。我们改进了我们自己以前的工作，在同一个数据集中只能找到36个问题。我们对<$Comment报告的412个问题进行了手动检查，结果显示它在报告关键评论克隆方面的准确率为79%。手动检查200个额外的评论克隆，<$Comment过滤出合法的，不能证明任何假阴性。
2021-08-25 cs.SE
The Paradox of Function Header Comments
本文通过调查367名开发者发现函数头注释存在“认可价值却不愿编写”的悖论，并提出基于签名相似性的无信息文档度量指标，在21,140个GitHub Python文件中验证了实际注释通常包含签名之外的额外信息。
2024-01-15 cs.SE
What Makes a Code Review Useful to OpenDev Developers? An Empirical Investigation
本研究通过混合方法调查OpenDev项目中代码评审评论的有用性，发现其受技术贡献和语言特征影响，评审经验正相关，而评审数量、文件评论量、行数及间隔负相关。
2023-06-19 cs.SE
Large Language Models are Few-Shot Summarizers: Multi-Intent Comment Generation via In-Context Learning
本研究针对现有代码注释生成方法仅能生成单条注释、无法满足开发者多样信息需求的问题，实证验证了采用上下文学习范式的大语言模型可生成多意图注释，且提示构建与后处理策略能进一步提升性能。
2023-06-14 cs.SE
Empirical Study on the Characteristics and Evolution of AI-usage in GitHub Repositories: Evidence from Code Comments
Missouri University of Science and Technology（密苏里科技大学）；Drexel University（德雷塞尔大学）
通过分析35,361条提及AI的GitHub代码注释及后续提交，发现开发者主要用LLM实现代码，随后频繁重构、集成和修复，AI引用从代码生成转向知识支持和代码增强。
2026-06-05 cs.SE
What Should Developers Be Aware Of? An Empirical Study on the Directives of API Documentation
应用程序编程接口（API）向开发人员公开，以便重用软件库。API指令是API文档中的自然语言语句，使开发人员了解与API使用相关的约束和指导原则。本文介绍了设计和面向对象的图书馆的API文档的指令的实证研究的结果。它的主要贡献是提出并广泛讨论了23种API指令的分类。
2012-05-29 cs.SE
Together or Apart? Investigating a mediator bot to aggregate bot's comments on pull requests
针对拉取请求中机器人评论造成的信息过载问题，本文设计并评估中介机器人 FunnelBot，并通过25名新人的受试者内研究为降低噪音、支持新人的机器人设计提供依据。
2022-08-08 cs.SE
A Survey on How Test Flakiness Affects Developers and What Support They Need To Address It
非确定性地通过和失败的测试用例，即所谓的非确定性测试，近年来已成为软件工程研究的一个热点领域。虽然这一研究重点已经得到了一些行业的热情认可，但以前的工作主要是通过挖掘软件存储库使用以代码为中心的方法来研究片状。然而，从软件仓库中提取的数据无法告诉我们开发人员如何看待漏洞：测试漏洞在开发人员的日常工作中有多普遍，它如何影响他们，最重要的是：他们希望我们研究人员做些什么？为了回答这些问题，我们调查了335名不同领域的专业软件开发人员和测试人员。调查对象确认，艾滋病毒检测是一个普遍而严重的问题，从而加强了正在进行的艾滋病毒检测研究。开发人员不太担心重新运行测试所导致的计算成本，而更多地担心对测试结果的信任丧失。因此，他们希望有IDE插件来检测测试代码，并对问题进行更好的可视化，特别是显示测试结果的仪表板;他们还希望有更多的培训和关于剥落的信息。这些重要方面需要研究人员和工具开发人员的关注。
2022-04-08 cs.SE
Wait For It: Identifying "On-Hold" Self-Admitted Technical Debt
自我承认的技术债务是指软件开发人员知道他们当前的实现不是最佳的，并使用源代码注释来表明这一点的情况。在这项工作中，我们假设有可能开发自动化技术来更详细地理解这些评论的子集，并提出工具支持，可以帮助开发人员更有效地管理自我承认的技术债务。基于对335条表明自我承认的技术债务的评论的定性研究，我们首先确定了一种适合自动化管理的特定债务类别：“搁置”自我承认的技术债务，即，债务，它包含一个条件，指示开发人员正在等待某个事件或已在其他地方实现的更新功能。然后，我们设计和评估一个自动分类器，它可以识别这些“等待”的情况下，在0.83的接收器工作特征曲线（AUC）的面积，以及检测开发人员正在等待的特定条件。我们的工作是迈向自动化工具支持的第一步，它能够指示何时可以解决某些自我承认的技术债务。
2019-10-21 cs.SE
Architecture Information Communication in Two OSS Projects: the Why, Who, When, and What
体系结构信息是开源软件开发的关键，邮件列表是开发人员共享和交流体系结构信息的常用渠道之一。本文研究了建筑信息交流的本质（即，why，who，when，and what）由OSS开发人员通过开发人员邮件列表。我们采用了多案例研究的方法来提取和分析架构信息通信从开发人员的邮件列表的两个OSS项目，ArgoUML和Hibernate，在其开发生命周期超过18年。我们的主要发现是：（a）架构协商和解释是两个主要原因（即，为什么）;（b）在开发者邮件列表中传送的体系结构信息的量在第一稳定版本之后减少（即，时）;（c）以少数核心开发人员为中心的体系结构通信（即，谁）;（d）和最频繁通信的体系结构元素（即，什么）是架构原理和架构模型。这两个OSS项目之间的架构通信有一些相似之处。这些相似之处表明，OSS开发人员自然倾向于OSS开发中架构通信的四个方面。
2021-07-03 cs.SE
What Do Developers Discuss in Their Workplace? An Analysis of Workplace StackExchange Discussions
本研究分析Workplace StackExchange的47,368篇帖子，识别出46个主题并归为七类，发现约30%的讨论涉及工作场所冲突，凸显其作为开发者最突出讨论主题的地位。
2024-11-11 cs.SE
Optimizing Deep Learning Models to Address Class Imbalance in Code Comment Classification
本文通过损失函数加权策略和超参数搜索微调 RoBERTa 模型，在 NLBSE'25 数据集上比 STACC 基线平均 F1c 提升 8.9 个百分点，有效缓解代码注释分类中的类别不平衡问题。
2025-01-27 cs.SE
How Developers and Managers Define and Trade Productivity for Quality
在本文中，我们提出了调查研究的结果，调查开发人员和管理人员如何定义和权衡开发人员的生产力和软件质量（两个相关的镜头到软件开发）。我们发现，开发人员和管理人员作为一个群体，在他们对生产力的看法上并不一致（开发人员认为生产力是从活动的角度来考虑的，而更多的管理人员认为生产力是从绩效的角度来考虑的）。我们还发现，开发人员在预测经理对生产力的看法方面并不准确。在质量方面，我们发现单个开发人员和管理人员对质量对他们意味着什么有着非常不同的看法，但作为群体，他们在不同的观点上是紧密一致的，两组中的大多数人都从健壮性的角度定义质量。超过一半的开发人员和管理人员报告说，质量可以换取更高的生产力，以及为什么这种权衡是合理的，而三分之一的人认为质量是生产力的必要组成部分，不能交易。我们还提出了一个新的描述性框架的质量，TRUCE，我们综合调查的反应。我们呼吁开发人员和管理人员之间就他们各自认为重要的软件质量属性进行更多的讨论，并就软件质量如何与开发人员的生产力以及应该或不应该进行哪些权衡进行公开辩论。
2022-04-27 cs.SE
What Drives and Sustains Self-Assignment in Agile Teams
自我分配，即软件开发人员选择自己的任务，是敏捷团队中的一种常见做法。但是，开发人员为什么选择某些任务尚不清楚。管理人员必须了解这些原因，以确保可持续的自我分配做法。我们调查了开发人员在为自己选择任务时的偏好。我们收集了来自25家不同软件公司的42名参与者的数据。我们应用扎根理论程序来研究和分析自我分配任务的因素，我们将其分为三类：基于任务的，基于开发人员的，基于意见的。我们发现开发人员有个人偏好，并非所有因素对每个开发人员都很重要。管理人员对所确定的因素有一些共同的和不同的看法。大多数经理希望开发人员对某些因素给予更高的优先级。开发人员经常需要在任务优先级和他们自己的个人偏好之间取得平衡，管理人员通过各种策略来促进这一点。更多规避风险的管理者鼓励基于专业知识的自我分配，以确保任务快速完成。风险平衡的管理者鼓励开发人员选择那些只有在延迟或质量降低的风险很小的情况下才能提供学习机会的任务。最后，寻求成长的经理经常鼓励团队成员选择舒适区之外的任务，以鼓励成长机会。我们的研究结果将帮助管理者了解开发人员在自我分配任务时会考虑什么，并帮助他们授权团队以可持续的方式实践自我分配。
2021-08-11 cs.SE
Generating Comments From Source Code with CCGs
好的注释可以帮助开发人员更快地理解软件，并提供更好的维护。然而，评论往往是失踪，一般不准确，或过时。这些问题中的许多可以通过自动注释生成来避免。本文提出了一种使用自然语言处理的通用技术直接从源代码生成信息性注释的方法。我们使用现有的自然语言模型，夫妇的话，他们的个人逻辑意义和语法规则，使评论生成进行搜索从声明性描述的程序文本的意见。我们评估我们的算法在Python中实现的几个经典算法。
2018-10-15 cs.SE
A Survey on What Developers Think About Testing
本调查基于284名开发者的回复，探究开发者对测试的真实态度，发现测试动机受质量追求与个人满足感驱动，但被视为单调任务，建议通过更好认可来改善。
2023-09-03 cs.SE
What Java Developers Know About Compatibility, And Why This Matters
真实世界的程序既不是单一的，也不是静态的--它们是使用平台和第三方库构建的，程序和库都在不断地发展以应对变化的压力。在Java语言的情况下，Java语言和Java虚拟机规范中定义的规则定义了何时库演化是安全的。这些规则区分了三种类型的兼容性-二进制，源代码和行为。我们声称，其中一些规则是违反直觉的，许多开发人员并没有很好地理解。我们提出了一项调查的结果，我们询问开发人员对各种类型的兼容性的理解。414名开发人员回应了我们的调查。我们发现，虽然大多数程序员都熟悉源代码兼容性的规则，但他们通常缺乏有关二进制和行为兼容性规则的知识。当组织从集成构建切换到需要动态链接的技术（如OSGi）时，这可能会产生问题。我们通过研究问题跟踪系统中与链接相关的问题被引用的频率来评估问题的严重性，并发现它们很常见。
2014-08-12 cs.SE
Beyond the Prompt: Linking What Developers Ask, Do, and Understand with Coding Agents
Oregon State University, School of Electrical Engineering and Computer Science（俄勒冈州立大学电气与计算机工程学院）
本文提出“说、做、理解”工作流程，通过提示、屏幕活动和事后解释分析开发者与编程智能体的交互，并在十名开发者使用GitHub Copilot的研究中识别出四种人物画像，揭示了任务表现与理解之间的分歧。
2026-09-29 cs.SE
"TODO: Fix the Mess Gemini Created": Towards Understanding GenAI-Induced Self-Admitted Technical Debt
Missouri University of Science and Technology（密苏里科技大学）
本文研究了GenAI在软件开发中导致的技术债务问题，提出GIST概念框架，分析开发者在使用AI生成代码时的自我承认行为及技术债务的产生原因。
2026-01-12 cs.SE
Investigating the Impact of Code Comment Inconsistency on Bug Introducing
本研究利用GPT-3.5探究代码注释不一致对缺陷引入的影响，验证了GPT-3.5在不一致检测上的优越性，发现不一致变更引发缺陷提交的概率约为一致变更的1.5倍，且影响随时间推移减弱。
2024-09-16 cs.SE
What Skills do IT Companies look for in New Developers? A Study with Stack Overflow Jobs
背景：对于IT公司如何寻找空缺职位候选人的信息的需求越来越大。目的：本文通过分析20，000个工作机会的描述来调查IT公司更需要哪些硬技能和软技能。方法：我们应用开放式卡片排序来进行高层次的分析，哪些类型的硬技能更需要。此外，我们手动分析了最常提到的软技能。结果：程序设计语言是最需要的硬技能。沟通、协作和解决问题是最需要的软技能。结论：我们建议开发人员根据他们申请的职位来组织他们的简历。我们还强调了软技能的重要性，因为它们出现在许多工作机会中。
2020-11-04 cs.SE
What Developers Ask to ChatGPT in GitHub Pull Requests? an Exploratory Study
本研究通过手动评估GitHub已合并PR中的155个ChatGPT分享链接，归类出14种请求类型，发现代码审查、代码片段实现等请求常见，且代码生成类提示词交互次数多于文本审查类，填补了开发者与ChatGPT代码贡献交互理解的空白。
2025-08-23 cs.SE
At What Cost? Software Developers' Well-Being in the Age of GenAI
Queen’s University（女王大学）；The University of Western Australia（西澳大学）；University of Otago（奥塔哥大学）；Uppsala University（乌普萨拉大学）
本文探讨了生成人工智能时代软件开发者福祉问题，指出过度关注生产力和性能可能忽视开发者身心健康，提出理论框架以平衡绩效指标与人类体验和社会可持续性。
2026-05-21 cs.SE
Code Comments for Quantum Software Development Kits: An Empirical Study on Qiskit
Beihang University（北京航空航天大学）
本文通过Qiskit提出首个量子计算代码注释数据集CC4Q，分析了量子软件注释的结构、开发者意图及量子主题，揭示了经典与量子软件注释的关键差异。
2025-11-30 cs.SE
Warnings: Violation Symptoms Indicating Architecture Erosion
本研究从开发者视角调查了代码评审评论中的架构违规症状特征，通过分析四个开源项目的606条评论，归纳出10类违规症状、常用术语与语言模式及解决措施，为理解架构侵蚀和改进开发维护实践提供了指导。
2023-08-04 cs.SE
BashExplainer: Retrieval-Augmented Bash Code Comment Generation based on Fine-tuned CodeBERT
开发人员将shell命令用于许多任务，例如文件系统管理、网络控制和进程管理。Bash是最常用的shell之一，在Linux系统开发和维护中起着重要的作用。由于Bash代码的语言灵活性，不熟悉Bash的开发人员通常很难理解Bash代码的目的和功能。本文研究了Bash代码注释生成问题，提出了一种基于两阶段训练策略的自动生成方法BashExplainer。在第一阶段，我们训练一个Bash编码器微调CodeBERT我们构建的Bash代码语料库。在第二阶段中，我们首先从代码库中检索最相似的代码为目标代码的语义和词汇相似性的基础上。然后我们使用训练好的Bash编码器生成两个矢量表示。最后，我们通过融合层融合这两个矢量表示，并通过解码器生成代码注释。为了显示我们所提出的方法的竞争力，我们构建了一个高质量的语料库相结合的语料库共享在以前的NL2Bash研究和共享的语料库在NLC2CMD竞争。该语料库包含10，592个Bash代码和相应的注释。然后，我们从以前关于自动代码注释生成的研究中选择了十个基线，其中包括信息检索方法，深度学习方法和混合方法。
2022-06-27 cs.SE
Release Practices for Mobile Apps--What do Users and Developers Think?
大型软件组织，如Facebook或Netflix，使用连续交付每天甚至每小时发布Web应用程序，不得不投入巨资为其移动应用程序定制发布策略，因为应用程序商店的审查过程会给发布过程带来滞后和不确定性。在这些大型的、资源丰富的组织中，我们不知道移动应用程序开发人员是如何组织应用程序发布的，即使不正确的策略可能会给市场带来过早的应用程序更新，从而将客户推向激烈的市场竞争。为了了解移动应用程序的常见发布策略、其背后的原理及其对用户的影响，我们对用户和开发人员进行了两次调查。我们发现，有一半的开发者对他们的移动应用发布有一个明确的策略，因为特别是经验丰富的开发者认为这会影响用户反馈。我们还发现，用户知道新的应用程序更新，但只有一半的受访用户启用自动更新的应用程序。虽然发布日期和频率不是安装应用程序的决定性因素，但用户更喜欢安装更新最近和更新频率较低的应用程序。我们的研究表明，应用程序的发布策略是影响移动应用程序持续成功的一个因素。
2019-10-20 cs.SE
Autonomy Is An Acquired Taste: Exploring Developer Preferences for GitHub Bots
软件机器人在集体软件开发中发挥着重要作用，开发人员采用它们可以提高生产力。过去的研究已经发现，通信过于频繁的机器人可能会激怒开发人员，从而影响机器人的效用。然而，目前尚不清楚人机协作的其他属性会影响开发人员的偏好，或者这些属性可能会产生什么影响。本文的主要思想是在GitHub拉取请求的背景下，探索影响开发人员对人类和机器人之间交互的偏好的特征。我们进行了一个探索性的连续研究与访谈和随后的基于插图的调查。我们发现开发人员通常更喜欢那些有个性但几乎没有自主性的机器人，然而，更有经验的开发人员倾向于更自主的机器人。基于这些经验证据，我们建议机器人程序开发人员增加机器人程序的配置选项，以便个人开发人员和项目可以配置机器人程序，以最好地符合他们自己的偏好和项目文化。
2023-02-10 cs.SE
From Generic to Personalized: Exploring Persona-Aware Code Review Explanations
University of Saskatchewan（萨斯喀彻温大学）；Singapore Management University（新加坡管理大学）；University of Hawai’i（夏威夷大学）
研究针对开发人员对代码审查评论理解不同的问题，探索个性化代码审查解释潜力。通过混合方法用户研究发现解释风格偏好因多种因素而异，据此勾勒出以人为本、适应开发者偏好的人工智能辅助代码审查系统愿景。
2026-07-13 cs.SE
It's Alive! What a Live Object Environment Changes in Software Engineering Practice
LIFIA, Fac. de Informática, Univ. Nac. de La Plata（拉普拉塔国立大学信息学院计算智能与信息系统实验室）；CONICET（阿根廷国家科学研究委员会）；Inria（法国国家数字科学研究所）
本文探讨了Pharo环境中活体对象环境对软件工程实践的影响，介绍了Inspector、Microcommits、Xtreme TDD等工具如何提升开发效率和工作流程。
2026-03-03 cs.SE
Performance Comparison of Binary Machine Learning Classifiers in Identifying Code Comment Types: An Exploratory Study
代码注释对源代码至关重要，因为它们有助于开发人员完成程序理解任务。代码注释是用自然语言（通常是英语）编写的，它传达各种不同的信息，这些信息被分组到特定的类别中。在这项研究中，我们构建了19个二进制机器学习分类器的代码注释类别，属于三种不同的程序设计语言。我们提出了不同类型的机器学习分类器的性能分数的比较，并表明线性SVC分类器具有最高的平均F1分数0.5474。
2023-03-03 cs.SE
To Copilot and Beyond: 22 AI Systems Developers Want Built
Oregon State University（俄勒冈州立大学）；Microsoft Research（微软研究院）
本文通过调研860名微软开发者，识别出22个AI系统需求，涵盖五个任务类别。研究发现开发者希望AI在早期工作流中嵌入质量信号，同时限制其权限和隐私，揭示了AI辅助开发中的'有界委托'模式。
2026-04-09 cs.SE
SmartDoc: A Context-Aware Agentic Method Comment Generation Plugin
Independent Researcher Shiraz Iran；Independent Researcher
本文提出名为SmartDoc的IntelliJ IDEA插件，作为AI智能体利用方法上下文和DFS遍历调用图丰富LLM提示，生成上下文感知的Java方法注释，在BERTScore等指标上达到0.80-0.90的准确率。
2025-11-01 cs.SE
Evaluating Non-English Developer Support in Machine Learning for Software Engineering
Delft University of Technology（代尔夫特理工大学）
研究评估非英语代码注释生成及现有评估方法的可靠性，发现非英语环境下生成性能显著下降，自动评估方法无法可靠区分正确与错误注释。
2026-05-07 cs.SE
Optimizing Knowledge Utilization for Multi-Intent Comment Generation with Large Language Models
School of Computer Software, Tianjin University（天津大学计算机科学与技术学院）；Faculty of Information Technology, Monash University（蒙纳士大学信息技术学院）
针对现有基于大语言模型的多意图代码注释生成方法难以在少量示例中构建正确关联的问题，提出KUMIC框架，通过检索高一致性示例和构建映射知识链优化知识利用，在多项指标上显著优于基线方法。
2025-10-29 cs.SE
What really changes when developers intend to improve their source code: a commit-level study of static metric value and static analysis warning changes
许多软件度量被设计用来度量那些被认为与软件质量相关的方面。静态软件度量，例如，规模、复杂性和耦合性被用于缺陷预测研究以及软件质量模型来评估软件质量。虽然这表明了质量和软件度量之间的关系，但它的程度还没有得到很好的理解。此外，最近的研究发现，复杂性度量可能是源代码可理解性的不可靠指标。为了探索这种关系，我们利用开发人员的意图，即什么构成了他们自己代码库的质量改进。我们通过检查提交消息，将来自54个Java开源项目的2，533个提交的随机样本手动分类为质量改进，这取决于开发人员的意图。我们通过预定义的指导方针区分完美和纠正性维护，并将这些数据用作基础事实，用于微调自然语言处理的最先进的深度学习模型。我们使用该模型将数据集增加到125，482次提交。基于由此产生的数据集，我们调查的差异大小和14静态源代码指标之间的变化，提高质量，由开发人员表示，和其他变化。我们发现，质量改善提交比其他提交更小。完美的更改对静态源代码指标有积极的影响，而纠正性更改则倾向于增加复杂性。此外，我们发现，文件的目标是完善的维护已经有一个较低的中位数比其他文件的复杂性。我们的研究结果提供了经验证据，静态源代码度量捕获质量改进从开发人员的角度来看。这对程序理解以及代码气味检测和推荐系统都有影响。
2022-05-30 cs.SE
Comment Generation for Source Code: State of the Art, Challenges and Opportunities
研究表明，当今软件开发的大部分工作是维护和演化。开发人员经常使用集成开发环境、调试器和工具进行代码搜索、测试和程序理解，以减少繁琐的任务。使软件开发更高效的一种方法是使程序更具可读性。为此目的提出和发展了许多办法。在这些方法中，源代码的注释生成越来越受到关注，并已成为一个热门的研究领域。本文总结了评论生成的研究现状，并讨论了评论生成所面临的挑战和未来的机遇。
2018-09-07 cs.SE
When simplicity meets effectiveness: Detecting code comments coherence with word embeddings and LSTM
针对代码注释不一致问题，提出Co3D方法，结合word2vec与LSTM等简单架构，在检测一致性上超越基线，证明简洁模型的有效性。
2024-05-28 cs.SE
To the Attention of Mobile Software Developers: Guess What, Test your App!
软件测试是软件开发生命周期中的一个重要阶段，因为它有助于在软件系统交付给最终用户之前识别软件系统中的错误。有许多关于开发人员如何测试通用软件应用程序的研究。然而，移动软件应用程序的特性将移动应用程序与通用系统（例如，桌面、独立应用程序、Web服务）。本文研究了移动软件开发人员在测试方面的工作习惯和挑战。我们使用1000个Android应用程序进行了详尽的研究，其中一个关键发现表明，移动应用程序仍然以非常特殊的方式进行测试，如果进行测试的话。然而，我们表明，与其他类型的软件一样，测试提高了应用程序的质量（在用户评分和代码问题数量中得到证明）。此外，我们发现有证据表明，在吸引社区为移动开源软件做出贡献时，测试至关重要。我们讨论的原因和潜在的方向，以解决我们的研究结果。我们研究的另一个相关发现是，持续集成和持续部署（CI/CD）管道在移动应用程序世界中很少见（只有26%的应用程序是在使用CI/CD的项目中开发的）-我们认为主要原因之一是由于缺乏详尽和自动测试。
2019-02-14 cs.SE
What Makes a Good TODO Comment?
本研究针对开源项目中大量低质量TODO注释的问题，调研了TODO注释质量的四个维度，提出高质量TODO识别标准，构建的深度学习方法可有效评估注释质量，助力提升开发效率与代码质量。
2025-03-19 cs.SE
What Do Developers Ask About ML Libraries? A Large-scale Study Using Stack Overflow
现代软件系统越来越多地将机器学习（ML）作为一个不可分割的组成部分。然而，我们还不了解软件开发人员在学习ML库并在其系统中使用它们时所面临的困难。为此，本文报告了对3,243篇与十个ML库（即Tensorflow、Keras、scikit-learn、Weka、Caffe、Theano、MLlib、Torch、Mahout和H2O）相关的高评价问答帖子的详细（手动）检查，这些帖子位于Stack Overflow（一个流行的在线技术问答论坛）上。我们将这些问题分为ML管道的七个典型阶段，以了解库和阶段之间的相关性。然后，我们研究的问题，并进行统计分析，以探索四个研究目标的答案（找到最困难的阶段，了解问题的性质，图书馆的性质和研究是否随着时间的推移保持一致的困难）。我们的研究结果表明，迫切需要在这一领域的软件工程（SE）的研究。静态分析和动态分析基本上都不存在，并且迫切需要帮助开发人员更早地发现错误。虽然已经有一些关于调试的早期研究，但还需要做更多的工作。API误用很普遍，迫切需要改进API设计。最后，有点令人惊讶的是，在提供更高级别的抽象和需要理解训练模型的行为之间的拔河是普遍的。
2019-06-27 cs.SE
Exploring the Advances in Identifying Useful Code Review Comments
本文系统梳理了代码评审评论有用性研究的发展，涵盖定义、数据集、开发者感知、影响因素和机器学习自动预测，并指出未来面临的开放问题与挑战。
2023-07-06 cs.SE
Developer Belief vs. Reality: The Case of the Commit Size Distribution
软件开发工具的设计遵循这些工具的开发人员对软件开发的信念。这种信念的一个关键方面是对软件项目的代码贡献（提交）的大小。在本文中，我们表明，工具开发人员认为是真实的代码贡献的大小是不同的，从现实中超过一个数量级。我们为开源和选定的闭源项目的大样本呈现了这个现实，称为提交大小分布。我们认为，这些新的经验性的见解将有助于提高软件开发工具，调整基本的设计假设更接近现实。
2014-08-20 cs.SE
Enhancing Code Generation via Bidirectional Comment-Level Mutual Grounding
Purdue University（普渡大学）
本文提出以可编辑代码注释为媒介的双向互证交互框架，通过代码、行内注释与用户反馈迭代对齐意图，显著提升LLM代码生成准确率与开发者任务表现。
2025-05-12 cs.AI cs.CL cs.SE
Is Agentic Code Review Helpful? Mining Developers' Feedback to CodeRabbit Reviews in the Wild
The University of Melbourne（墨尔本大学）；Monash University（莫纳什大学）
以CodeRabbit为例对智能代码审查进行实证研究，通过大量代码审查与开发者反馈数据，揭示其审查结果及被拒原因，还探索预测审查被拒的方法，指出改进空间与不足。
2026-07-24 cs.AI cs.SE
