1,825 research outputs found
Coeditor: Leveraging Contextual Changes for Multi-round Code Auto-editing
Developers often dedicate significant time to maintaining and refactoring
existing code. However, most prior work on generative models for code focuses
solely on creating new code, neglecting the unique requirements of editing
existing code. In this work, we explore a multi-round code auto-editing
setting, aiming to predict edits to a code region based on recent changes
within the same codebase. Our model, Coeditor, is a fine-tuned CodeT5 model
with enhancements specifically designed for code editing tasks. We encode code
changes using a line diff format and employ static analysis to form large
customized model contexts, ensuring appropriate information for prediction. We
collect a code editing dataset from the commit histories of 1650 open-source
Python projects for training and evaluation. In a simplified single-round,
single-edit task, Coeditor significantly outperforms the best code completion
approach -- nearly doubling its exact-match accuracy, despite using a much
smaller model -- demonstrating the benefits of incorporating editing history
for code completion. In a multi-round, multi-edit setting, we observe
substantial gains by iteratively prompting the model with additional user
edits. We open-source our code, data, and model weights to encourage future
research and release a VSCode extension powered by our model for interactive
usage
Recommended from our members
An empirical investigation into the impact of refactoring on regression testing
It is widely believed that refactoring improves software quality and developerโs productivity by making it easier to maintain and understand software systems. On the other hand, some believe that refactoring has the risk of functionality regression and increased testing cost. This paper investigates the impact of refactoring edits on regression tests using the version history of Java open source projects: (1) Are there adequate regression tests for refactoring in practice? (2) How many of existing regression tests are relevant to refactoring edits and thus need to be re-run for the new version? (3) What proportion of failure-inducing changes are relevant to refactorings? By using a refactoring reconstruction analysis and a change impact analysis in tandem, we investigate the relationship between the types and locations of refactoring edits identified by RefFinder and the affecting changes and affected tests identified by the FaultTracer change impact analysis. The results on three open source projects, JMeter, XMLSecurity, and ANT, show that only 22% of refactored methods and fields are tested by existing regression tests. While refactorings only constitutes 8% of atomic changes, 38% of affected tests are relevant to refactorings. Furthermore, refactorings are involved in almost a half of failed test cases. These results call for new automated regression test augmentation and selection techniques for validating refactoring edits.Electrical and Computer Engineerin
The Impact of Systematic Edits in History Slicing
While extracting a subset of a commit history, specifying the necessary
portion is a time-consuming task for developers. Several commit-based history
slicing techniques have been proposed to identify dependencies between commits
and to extract a related set of commits using a specific commit as a slicing
criterion. However, the resulting subset of commits become large if commits for
systematic edits whose changes do not depend on each other exist. We
empirically investigated the impact of systematic edits on history slicing. In
this study, commits in which systematic edits were detected are split between
each file so that unnecessary dependencies between commits are eliminated. In
several histories of open source systems, the size of history slices was
reduced by 13.3-57.2% on average after splitting the commits for systematic
edits.Comment: 5 pages, MSR 201
A heuristic-based approach to code-smell detection
Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together โ data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache
Structured Review of Code Clone Literature
This report presents the results of a structured review of code clone literature. The aim of the review is to assemble a conceptual model of clone-related concepts which helps us to reason about clones. This conceptual model unifies clone concepts from a wide range of literature, so that findings about clones can be compared with each other
Perception and Acceptance of an Autonomous Refactoring Bot
The use of autonomous bots for automatic support in software development
tasks is increasing. In the past, however, they were not always perceived
positively and sometimes experienced a negative bias compared to their human
counterparts. We conducted a qualitative study in which we deployed an
autonomous refactoring bot for 41 days in a student software development
project. In between and at the end, we conducted semi-structured interviews to
find out how developers perceive the bot and whether they are more or less
critical when reviewing the contributions of a bot compared to human
contributions. Our findings show that the bot was perceived as a useful and
unobtrusive contributor, and developers were no more critical of it than they
were about their human colleagues, but only a few team members felt responsible
for the bot.Comment: 8 pages, 2 figures. To be published at 12th International Conference
on Agents and Artificial Intelligence (ICAART 2020
- โฆ