Rename method

Abstract: Understanding how developers refactor their code is critical to support the design improvement process of software. This paper investigates to what extent code metrics are good indicators for predicting refactoring activity in the source code. In order to perform this, we formulated the prediction of refactoring operation types as a multi-class classification problem. Our solution relies on measuring metrics extracted from committed code changes in order to extract the corresponding features (i.e., metric variations) that better represent each class (i.e., refactoring type) in order to automatically predict, for a given commit, the method-level type of refactoring being applied, namely Move Method, Rename Method, Extract Method, Inline Method, Pull-up Method, and Push-down Method. We compared various classifiers, in terms of their prediction performance, using a dataset of 5004 commits and extracted 800 Java projects. Our main findings show that the random forest model trained with code metrics resulted in the best average accuracy of 75%. However, we detected a variation in the results per class, which means that some refactoring types are harder to detect than others.

Abstract: Today, it is widely accepted that if refactoring is applied in practice, it is mainly interweaved with normal software development - so called "floss refactoring". Unfortunately, the current state-of-the-art is poorly equipped to mine floss refactoring from version histories, mainly because they infer refactorings by comparing two snapshots of a system and making educated guesses about the precise edit operations applied in between. In this paper we propose a solution that reconstructs refactorings not on snapshots of a system but using the actual changes as they are performed in an integrated development environment. We compare our solution against RefFinder and demonstrate that on a small yet representative program (the well-known "Video Rental system") our approach is more accurate in identifying occurrences of the "Move Method" and "Rename Method" refactorings.

Abstract: A previous study by Bieman et al., investigated whether large, object-oriented classes were more susceptible to change than smaller classes. The measure of change used in the study was the frequency with which the features of a class had been changed over a specific period of time. From a refactoring perspective, the frequency of class change is of value But even for a relatively simple refactoring such as 'rename method', multiple classes may undergo minor modification without any net increase in class (and system) size. In this paper, we suggest that the combination of 'versions of a class and number of added lines of code ' in the bad code 'smell' detection process may give a better impression of which classes are most suitable candidates for refactoring; as such, effort in detecting bad code smells should apply to classes with a high growth rate as well as a high change frequency. To support our investigation, data relating to changes from 161 Java classes was collected. Results concluded that it is not necessarily the case that large classes are more change-prone than relatively smaller classes. Moreover, the bad code smell detection process is informed by using the combination of change frequency and class size as a heuristic.

Abstract: Refactorings might be done using two different tactics: root canal refactoring and floss refactoring. Root canal refactoring is to set aside an extended period specially for refactoring. Floss refactoring is to interleave refactorings with other programming tasks. However, no large-scale case study on refactoring tactics is available. To this end, the authors carry out a case study to investigate the following research questions. (i) How often are root canal refactoring and floss refactoring employed, respectively? (ii) Are some kinds of refactorings more likely than others to be applied as floss refactorings or root canal refactorings? (iii) Do engineers employing both tactics have obvious bias to or against either of the tactics? They analyse the usage data information collected by Eclipse usage data collector. Results suggest that about 14% of refactorings are root canal refactorings. These findings reconfirm the hypothesis that, in general, floss refactoring is more common than root canal refactoring. The relative popularity of root canal refactoring, however, is much higher than expected. They also find that some kinds of refactorings are more likely than others to be performed as root canal refactorings. Results also suggest that engineers who have explored both tactics obviously tended towards root canal refactoring.