Why Do Developers Reject Refactorings in Open-Source Projects?

2022 ◽  
Vol 31 (2) ◽  
pp. 1-23
Author(s):  
Jevgenija Pantiuchina ◽  
Bin Lin ◽  
Fiorella Zampetti ◽  
Massimiliano Di Penta ◽  
Michele Lanza ◽  
...  

Refactoring operations are behavior-preserving changes aimed at improving source code quality. While refactoring is largely considered a good practice, refactoring proposals in pull requests are often rejected after the code review. Understanding the reasons behind the rejection of refactoring contributions can shed light on how such contributions can be improved, essentially benefiting software quality. This article reports a study in which we manually coded rejection reasons inferred from 330 refactoring-related pull requests from 207 open-source Java projects. We surveyed 267 developers to assess their perceived prevalence of these identified rejection reasons, further complementing the reasons. Our study resulted in a comprehensive taxonomy consisting of 26 refactoring-related rejection reasons and 21 process-related rejection reasons. The taxonomy, accompanied with representative examples and highlighted implications, provides developers with valuable insights on how to ponder and polish their refactoring contributions, and indicates a number of directions researchers can pursue toward better refactoring recommenders.

Author(s):  
Himanshi Vashisht ◽  
Sanjay Bharadwaj ◽  
Sushma Sharma

Code refactoring is a “Process of restructuring an existing source code.”. It also helps in improving the internal structure of the code without really affecting its external behaviour”. It changes a source code in such a way that it does not alter the external behaviour yet still it improves its internal structure. It is a way to clean up code that minimizes the chances of introducing bugs. Refactoring is a change made to the internal structure of a software component to make it easier to understand and cheaper to modify, without changing the observable behaviour of that software component. Bad smells indicate that there is something wrong in the code that have to refactor. There are different tools that are available to identify and emove these bad smells. A software has two types of quality attributes- Internal and external. In this paper we will study the effect of clone refactoring on software quality attributes.


Author(s):  
Amanda Damasceno Santana ◽  
Eduardo Figueiredo

When a system evolution is not planned, developers can take decisions that degrade the system quality. To cope with this problem, refactoring can be applied to the source code aiming to increase code quality without modifying the software external behavior. To know when to refactor, the concept of bad smells can be used. Bad smells are snippets of source code that suggest the need of refactoring. However, bad smells does not always appear isolated. The aim of this study is to understand the impact of bad smell agglomerations on the software quality by evaluating a large dataset of open source systems. To achieve our goal, we plan to use data mining techniques complemented with correlation analysis of the dataset.


Algorithms ◽  
2020 ◽  
Vol 13 (7) ◽  
pp. 168
Author(s):  
Lerina Aversano ◽  
Martina Iammarino ◽  
Mimmo Carapella ◽  
Andrea Del Vecchio ◽  
Laura Nardi

The technical debt (TD) in a software project refers to the adoption of an inadequate solution from its design to the source code. When developers admit the presence of technical debt in the source code, through comments or commit messages, it is called self-admitted technical debt (SATD). This aspect of TD has been the subject of numerous research studies, which have investigated its distribution, the impact on software quality, and removal. Therefore, this work focuses on the relationship between SATD and TD values. In particular, the study aims to compare the admitted technical debt with respect to its objective measure. In fact, the trends of TD values during SATD removals have been studied. This was done thanks to the use of an SATD dataset and their related removals in four open source projects. Instead, the SonarQube tool was used to measure TD values. Thanks to this work, it turned out that SATD removals in a few cases correspond to an effective reduction of TD values, while in numerous cases, the classes indicated are removed.


2020 ◽  
Author(s):  
Θεόδωρος Αμανατίδης

Σχεδόν όλα τα συστήματα λογισμικού εξελίσσονται συνεχώς για να ικανοποιήσουν νέες ανάγκες και να προσαρμοστούν στις μεταβαλλόμενες απαιτήσεις της εποχής. Η ανάλυση εξέλιξης λογισμικού μπορεί να αποκαλύψει σημαντικές πληροφορίες σχετικά με τις πρακτικές συντήρησης που ακολουθούνται από τις ομάδες προγραμματιστών. Ο στόχος της διδακτορικής διατριβής είναι να μελετήσει την εξέλιξη των εφαρμογών ανοικτού κώδικα διερευνώντας την εξέλιξη της ποιότητας του λογισμικού καθώς και του κόστους συντήρησης, όπως αποτυπώνεται από τη έννοια του Τεχνικού Χρέους (ΤΧ). Το Τεχνικό Χρέος είναι μια έννοια στον προγραμματισμό που αντικατοπτρίζει την επιπλέον προσπάθεια συντήρησης που προκύπτει όταν αναπτύσσεται «μη-βέλτιστος» κώδικας, που είναι εύκολο να παραδοθεί γρήγορα, αντί να εφαρμόζονται οι βέλτιστες πρακτικές. Η διατριβή διερευνά την διαχρονική εξέλιξη ενός μεγάλου αριθμού εφαρμογών ανοιχτού κώδικα. Οι εφαρμογές αναλύθηκαν στο πλαίσιο των οκτώ (8) νόμων του Lehman περί εξέλιξης λογισμικού και ειδικότερα, εξετάστηκε εάν οι νόμοι επιβεβαιώνονται στην πράξη για διαδικτυακές εφαρμογές ανοιχτού κώδικα. Οι οκτώ νόμοι του Lehman αναφορικά είναι: Συνεχής Αλλαγή (Νόμος I), Αυξανόμενη Πολυπλοκότητα (Νόμος II), Αυτορρύθμιση (Νόμος III), Διατήρηση της Οργανωτικής Σταθερότητας (Νόμος IV), Διατήρηση της Eξοικείωσης (Νόμος V), Συνεχής Ανάπτυξη (Νόμος VI) Φθίνουσα Ποιότητα (VII) και Σύστημα Ανατροφοδότησης (VIII). Τα αποτελέσματα παρέχουν ευρήματα ότι η εξέλιξη των διαδικτυακών εφαρμογών συμμορφώνεται με τους περισσότερους νόμους. Τα τελευταία χρόνια, η έννοια του ΤΧ έχει γνωρίσει αυξανόμενη προσοχή από την ερευνητική κοινότητα. Συγκεκριμένα, μεγάλο μέρος των ερευνητικών μελετών επικεντρώθηκε στην έννοια του επιτοκίου Τεχνικού Χρέους, το οποίο αντικατοπτρίζει την πρόσθετη προσπάθεια συντήρησης που προκύπτει λόγω της ύπαρξης μη-βέλτιστου λογισμικού (δηλαδή, λόγω της ύπαρξης τεχνικού χρέους). Ακολουθώντας τις τάσεις της σύγχρονης έρευνας στη διαχείριση του TD, η διατριβή είχε ως στόχο τη διερεύνηση του αντίκτυπου του ΤΧ στη διορθωτική συντήρηση και συγκεκριμένα, σε ποιο βαθμό η παρουσία του ΤΧ καθυστερεί τον ρυθμό ανάπτυξης του λογισμικού αυξάνοντας τον χρόνο και την προσπάθεια που απαιτείται για τη διόρθωση σφαλμάτων. Παρόλο που το ΤΧ εκτιμάται και ποσοτικοποιείται συνήθως είτε σε ολόκληρο το σύστημα είτε σε μεμονωμένες μονάδες λογισμικού (αρχεία ή κλάσεις), η πραγματική αιτία για την συσσώρευση του ΤΧ είναι οι ίδιοι οι προγραμματιστές μέσω των πρακτικών που ακολουθούν κατά την ανάπτυξη κώδικα. Έτσι, η διατριβή επιχειρεί να διερευνήσει τη σχέση μεταξύ των χαρακτηριστικών των προγραμματιστών και της τάσης που έχουν να εισαγάγουν ΤΧ στο λογισμικό. Παρά το γεγονός ότι το ΤΧ έχει καθιερωθεί στην κοινότητα της Τεχνολογίας Λογισμικού, παραμένει μια μεταφορά και όπως όλες οι μεταφορές, αποτελεί μια αφηρημένη έννοια. Αυτό σημαίνει ότι ο τρόπος που ορίζεται και ερμηνεύεται από τους μηχανικούς λογισμικού είναι υποκειμενικός. Κάθε προγραμματιστής έχει τη δική του αντίληψη σχετικά με την σοβαρότητα του ΤΧ που εντοπίζεται στο λογισμικό του. Υπάρχουν πολλές φωνές που αμφισβητούν την εγκυρότητα του τρόπου ανίχνευσης και υπολογισμού του ΤΧ με τη χρήση αυτοματοποιημένων εργαλείων στατικής ανάλυσης (static analysis of source code). Με αφορμή τα παραπάνω, στο πλαίσιο αυτής της διατριβής εστάλη μια έρευνα σε ένα μεγάλο αριθμό προγραμματιστών που εμπλέκονται στην ανάπτυξη διαδικτυακών εφαρμογών ανοιχτού κώδικα. Η έρευνα, που είχε την μορφή online ερωτηματολογίου, στόχο είχε να αντλήσει πληροφορίες σχετικά με τους παράγοντες που οδηγούν τους προγραμματιστές να αποδεχτούν ή να απορρίψουν διορθώσεις που προτείνονται από αυτοματοποιημένα εργαλεία μέτρησης ΤΧ. Τα υπάρχοντα εργαλεία αξιολόγησης ΤΧ ακολουθούν διαφορετική προσέγγιση και κανόνες για την ποσοτικοποίηση του ΤΧ το καθένα. Κατά συνέπεια, το κάθε εργαλείο παράγει διαφορετικά αποτελέσματα από τα άλλα με αποτέλεσμα να μην υπάρχει μία αντικειμενική βάση για τα ποιο εργαλείο παράγει τα πιο ρεαλιστικά αποτελέσματα. Η προτεινόμενη διατριβή, προσπαθώντας να προσφέρει μία λύση στην έλλειψη της αντικειμενικότητας γύρω από την μέτρηση του ΤΧ, επιχειρεί να εντοπίσει σύνολα αρχείων/κλάσεων στα οποία εντοπίστηκε υψηλό ΤΧ ταυτόχρονα από τρία (3) ευρέως χρησιμοποιούμενα εργαλεία ΤΧ (CAST AIP, Squore και SonarQube). Αυτά τα αρχεία/κλάσεις υψηλού ΤΧ μπορούν να αποτελέσουν σημείο αναφοράς επικυρωμένων μονάδων υψηλού ΤΧ και με αυτόν τον τρόπο μπορεί να δημιουργηθεί μια βάση που θα συνδράμει στην κατάρτιση πιο εξελιγμένων τεχνικών αναγνώρισης ΤΧ. Παράλληλα, η διατριβή προτείνει μια στατιστική μεθοδολογία για την έγκυρη εξαγωγή του προαναφερόμενου συνόλου αρχείων/κλάσεων με υψηλό ΤΧ.


Software quality aims at having quality as part of all aspects of the developed software. Design smells are considered enemies of the software source code quality. There are verities of design problems with different terminologies. Researchers and practitioners accept it as true that whenever there is a design smell, there is a security issue or concern. In this work, we want to explore the connection between design smells and security vulnerabilities. This work provides experimental evidence about this connection. We conducted an empirical study to explore the connection between design smells and security issues by evaluating four C# open-source systems. We found interesting results that show classes with design smells have more chances of having security issues.


2021 ◽  
Author(s):  
Remo Gresta ◽  
Elder Cirilo

Identifiers represent approximately 2/3 of the elements in source code, and their names directly impact code comprehension. Indeed, intention-revealing names make code easier to understand, especially in code review sessions, where developers examine each other's code for mistakes. However, we argue that names should be understandable and pronounceable to enable developers to review and discuss code effectively. Therefore, we carried out an empirical study based on 40 open-source projects to explore the naming practices of developers concerning word complexity and pronounceability. We applied the Word Complexity Measure (WCM) to discover complex names; and analyzed the phonetic similarity among names and hard-to-pronounce English words. As a result, we observed that most of the analyzed names are somewhat composed of hard-to-pronounce words. The overall word complexity score of the projects also tends to be significant. Finally, the results show that the code location impacts the word complexity: names in small scopes tend to be simpler than names declared in large scopes.


Information ◽  
2018 ◽  
Vol 9 (11) ◽  
pp. 273 ◽  
Author(s):  
Aloisio Cairo ◽  
Glauco Carneiro ◽  
Miguel Monteiro

Context: Code smells are associated to poor design and programming style, which often degrades code quality and hampers code comprehensibility and maintainability. Goal: identify published studies that provide evidence of the influence of code smells on the occurrence of software bugs. Method: We conducted a Systematic Literature Review (SLR) to reach the stated goal. Results: The SLR selected studies from July 2007 to September 2017, which analyzed the source code of open source software projects and several code smells. Based on evidence of 16 studies covered in this SLR, we conclude that 24 code smells are more influential in the occurrence of bugs relative to the remaining smells analyzed. In contrast, three studies reported that at least 6 code smells are less influential in such occurrences. Evidence from the selected studies also point out tools, techniques, and procedures that should be applied to analyze the influence of the smells. Conclusions: To the best of our knowledge, this is the first SLR to target this goal. This study provides an up-to-date and structured understanding of the influence of code smells on the occurrence of software bugs based on findings systematically collected from a list of relevant references in the latest decade.


Sign in / Sign up

Export Citation Format

Share Document