Automated Program Repair (APR) has advanced significantly with the emergence of pre-trained Code Language Models (CLMs), enabling the generation of high-quality patches. However, selecting the most suitable CLM for APR remains challenging due to a range of factors, including accuracy, efficiency, and scalability, among others. These factors are interdependent and interact in complex ways, making the selection of a CLM for APR a multifaceted problem.

Refactoring, as one of the best practices in software development, has been also the centre of attention of much research. Particularly, a plethora of studies have been performed to understand the impact of refactorings on different dimensions of software development including software quality, program comprehension, fault-proneness, and non-functional requirements, among others. Among the employed approaches, analysing refactorings applied previously in real-world scenarios has been used by many researchers and proves to be a valuable way to delve deeper into the subject. The results of these research studies not only enhance our understanding of the advantages and potential drawbacks of refactorings but also guide us in developing more efficient automated refactoring tools based on how developers actually use refactorings in practice. However, the majority of studies in this regard have focused on refactorings applied in Java programs, and the other programming languages have received significantly less attention. In reality, the lack of comprehensive datasets of real-world applied refactorings makes it challenging for researchers to conduct comprehensive studies in programming languages other than Java. The primary obstacle can be the lack of automated tool support for identifying refactorings applied in programs implemented in other languages. To mitigate this limitation, we extended a previously available refactoring detection tool, Refdetect, to be able to identify refactorings applied in Kotlin programs. We conducted an experiment on 200 commits of 10 Kotlin repositories sourced on GitHub and compared the performance of our tool with an existing Kotlin refactoring detection tool called Ko T L I Nrmi Ne R. We found that our tool has a precision of 90% and a recall of 82 %, achieving an average F -score of 84 % which is 17 % better than the one achieved by KOTLINRMINER. We also provide the resulting dataset containing 2,043 true refactoring instances detected by at least one of Refdetect or Kotlinrminer and validated by one up to three refactoring experts. By releasing this initial dataset, we aim to address the existing gap in the availability of Kotlin refactoring datasets.

Abstract Refactoring source code involves the developer in a myriad of program detail that can obscure the design changes that they actually wish to bring about. On the other hand, refactoring a UML model of the code makes it easier to focus on the program design, but the burdensome task of applying the refactorings to the source code is left to the developer. In an attempt to obtain the advantages of both approaches, we propose a refactoring approach where the interaction with the developer takes place at the model level, but the actual refactoring occurs on the source code itself. We call this approach model‐based source code refactoring and implement it in this paper using two tools: (1) Design‐Imp enables the developer to use interactive search‐based design exploration to create a UML‐based desired design from an initial design extracted from the source code. It also provides visual cues to improve developer comprehension during the design‐level refactoring process and to help the developer to discern between promising and poor refactoring solutions. (2) Code‐Imp then refactors the original source so that it has the same functional behavior as the original program, and a design close to the one produced in the design exploration phase, that is, a design that has been confirmed as “desirable” by the developer. We evaluated our approach involving interaction and visual cues with industrial developers refactoring three Java projects, comparing it with an approach using interaction without visual cues and a fully automated approach. The results show that our approach yields refactoring sequences that are more acceptable both to the individual developer and to a set of independent expert refactoring evaluators. Furthermore, our approach removed more code smells and was evaluated very positively by the experiment participants.

In spite of several decades of software metrics research and practice, there is little understanding of how software metrics relate to one another, nor is there any established methodology for comparing them. We propose a novel experimental technique, based on search-based refactoring, to ‘animate’ metrics and observe their behaviour in a practical setting. Our aim is to promote metrics to the level of active, opinionated objects that can be compared experimentally to uncover where they conflict, and to understand better the underlying cause of the conflict. Our experimental approaches include semi-random refactoring, refactoring for increased metric agreement/disagreement, refactoring to increase/decrease the gap between a pair of metrics, and targeted hypothesis testing. We apply our approach to five popular cohesion metrics using ten real-world Java systems, involving 330,000 lines of code and the application of over 78,000 refactorings. Our results demonstrate that cohesion metrics disagree with each other in a remarkable 55 % of cases, that Low-level Similarity-based Class Cohesion (LSCC) is the best representative of the set of metrics we investigate while Sensitive Class Cohesion (SCOM) is the least representative, and we discover several hitherto unknown differences between the examined metrics. We also use our approach to investigate the impact of including inheritance in a cohesion metric definition and find that doing so dramatically changes the metric.

A large number of software metrics have been proposed in the literature, but there is little understanding of how these metrics relate to one another. We propose a novel experimental technique, based on search-based refactoring, to assess software metrics and to explore relationships between them. Our goal is not to improve the program being refactored, but to assess the software metrics that guide the auto- mated refactoring through repeated refactoring experiments.