Abstract Design Pattern Detection (DPD) tools are useful to support to the comprehension and maintenance of software systems. Although several DPD tools have been introduced over the years, they typically focus on a limited set of design patterns and programming languages. This paper aims to investigate (i) the reasons that motivate DPD tool designers to target specific design patterns and programming languages, and (ii) how potential users perceive the usefulness of DPD tools in practical software development scenarios. We conducted two online surveys. For the first survey, we reached out to designers of 42 DPD tools selected from a systematic literature review to obtain their perspectives on design decisions about pattern and language coverage, receiving 22% of such responses. For the second survey, we recruited 28 student and senior developers to help us understand their expectations, perceived benefits, and concerns related to the use of DPD tools. Within our sample, the findings suggest that participating tool designers often prioritize design patterns whose internal structure facilitates automated detection, while language support is frequently motivated by popularity and expected demand. From the perspective of tool users, DPD tools are expected to support development activities, such as program comprehension and software quality improvement. Unfortunately, usability difficulties, limited accuracy, and insufficient documentation often discourage them from adopting a tool. The responses suggest that some design decisions reported by participating DPD tool designers are aligned with practical and industrial considerations. However, the recurring lack of adequate documentation and usability support is a major barrier to wider usage. Taken as indicative evidence, these results suggest that future DPD tools should better balance detection capabilities and usability concerns, especially to meet the need of less experienced developers. Given the limited number of tool-designer respondents, conclusions about design rationale should be interpreted as indicative rather than representative of all DPD tool designers.

Several refactorings performed while evolving software features aim to improve internal quality attributes like cohesion and complexity. Indeed, internal attributes can become critical if their measurements assume anomalous values. Yet, current knowledge is scarce on how developers perceive the relevance of critical internal attributes while evolving features. This qualitative study investigates the developers’ perception of the relevance of critical internal attributes when evolving features. We target six class-level critical attributes: low cohesion, high complexity, high coupling, large hierarchy depth, large hierarchy breadth, and large size. We performed two industrial case studies based on online focus group sessions. Developers discussed how much (and why) critical attributes are relevant when adding or enhancing features. We assessed the relevance of critical attributes individually and relatively, the reasons behind the relevance of each critical attribute, and the interrelations of critical attributes. Low cohesion and high complexity were perceived as very relevant because they often make evolving features hard while tracking failures and adding features. The other critical attributes were perceived as less relevant when reusing code or adopting design patterns. An example of perceived interrelation is high complexity leading to high coupling.

Context: The success of Open Source Software (OSS) projects typically depends on simultaneous contributions of several developers. These contributions often affect the same changing source files and may lead to merge conflicts when integrated. Previous studies investigated the reduction of conflicting merge scenarios. However, empirical evidence on the involvement of OSS contributors in conflicting merge scenarios is scarce. Objective: We aim to fill this gap with a large-scale quantitative study with the goal of understanding: 1) the extent in which OSS contributors are involved in conflicting merge scenarios; 2) characteristics of these contributors; and 3) characteristics of changing source files. Method: We collect both contributor data and contribution data from 66 popular GitHub projects and analyze data of 2972 distinct contributors who were involved in at least one conflicting merge scenario. We rely on both descriptive and inferential statistics to address our research questions. Results: About 80% of the analyzed contributors are involved in only one or two conflicting merge scenarios. Additionally, 42 out of the 66 projects had its top-one contributor as the one mostly involved in conflicting merge scenarios. Finally, only a small set of changing source files are involved in conflicting merge scenarios. Conclusions: We advocate that training the typically small group of contributors involved in conflicting merge scenarios could significantly reduce the number of merge conflicts.

Program refactoring consists of code changes applied to improve the internal structure of a program and, as a consequence, its comprehensibility. Recent studies indicate that developers often perform composite refactorings, i.e., a set of two or more interrelated single refactorings. Recent studies also recommend certain patterns of composite refactorings to fully remove poor code structures, i.e, code smells, thus further improving the program comprehension. However, other recent studies report that composite refactorings often fail to fully remove code smells. Given their failure to achieve this purpose, these composite refactorings are considered incomplete, i.e, they are not able to entirely remove a smelly structure. Unfortunately, there is no study providing an in-depth analysis of the incompleteness nature of many composites and their possibly partial impact on improving, maybe decreasing, internal quality attributes. This paper identifies the most common forms of incomplete composites, and their effect on quality attributes, such as coupling and cohesion, which are known to have an impact on program comprehension. We analyzed 353 incomplete composite refactorings in 5 software projects, two common code smells (Feature Envy and God Class), and four internal quality attributes. Our results reveal that incomplete composite refactorings with at least one Extract Method are often (71%) applied without Move Methods on smelly classes. We have also found that most incomplete composite refactorings (58%) tended to at least maintain the internal structural quality of smelly classes, thereby not causing more harm to program comprehension. We also discuss the implications of our findings to the research and practice of composite refactoring.

Background: Code refactoring aims to improve code structures via code transformations. A single transformation rarely suffices to fully remove code smells that reveal poor code structures. Most transformations are applied in batches, i.e. sets of interrelated transformations, rather than in isolation. Nevertheless, empirical knowledge on batch application, or batch refactoring, is scarce. Such scarceness helps little to improve current refactoring practices. Aims: We analyzed 57 open and closed software projects. We aimed to understand batch application from two perspectives: characteristics that typically constitute a batch (e.g., the variety of transformation types employed), and the batch effect on smells. Method: We analyzed 19 smell types and 13 transformation types. We identified 4,607 batches, each applied by the same developer on the same code element (method or class); we expected to have batches whose transformations are closely interrelated. We computed (1) the frequency in which five batch characteristic manifest, (2) the probability of each batch characteristics to remove smells, and (3) the frequency in which batches introduce and remove smells. Results: Most batches are quite simple: although most batches are applied on more than one method (90%), they are usually composed of the same transformation type (72%) and only two transformations (57%). Batches applied on a single method are 2.6 times more prone to fully remove smells than batches affecting more than one method. Surprisingly, batches mostly ended up introducing (51%) or not fully removing (38%) smells. Conclusions: The batch simplicity suggests that developers have sub-explored the combinations of transformations within a batch. We summarized some batches that may fully remove smells, so that developers can incorporate them into current refactoring practices.

Bad smells are symptoms of problems in the source code of software systems. They may harm the maintenance and evolution of systems on different levels. Thus, detecting smells is essential in order to support the software quality improvement. Since even small systems may contain several bad smell instances, and considering that developers have to prioritize their elimination, its automated detection is a necessary support for developers. Regarding that, detection strategies have been proposed to formalize rules to detect specific bad smells, such as Large Class and Feature Envy. Several tools like JDeodorant and JSpIRIT implement these strategies but, in general, they do not provide full customization of the formal rules that define a detection strategy. In this paper, we propose FindSmells, a tool for detecting bad smells in software systems through software metrics and their thresholds. With FindSmells, the user can compose and manage different strategies, which run without source code analysis. We also provide a running example of the tool. Video: https://youtu.be/LtomN93y6gg.

Bad smells are symptoms that something may be wrong in the system design or code. There are many bad smells defined in the literature and detecting them is far from trivial. Therefore, several tools have been proposed to automate bad smell detection aiming to improve software maintainability. However, we lack a detailed study for summarizing and comparing the wide range of available tools. In this paper, we first present the findings of a systematic literature review of bad smell detection tools. As results of this review, we found 84 tools; 29 of them available online for download. Altogether, these tools aim to detect 61 bad smells by relying on at least six different detection techniques. They also target different programming languages, such as Java, C, C++, and C#. Following up the systematic review, we present a comparative study of four detection tools with respect to two bad smells: Large Class and Long Method. This study relies on two software systems and three metrics for comparison: agreement, recall, and precision. Our findings support that tools provide redundant detection results for the same bad smell. Based on quantitative and qualitative data, we also discuss relevant usability issues and propose guidelines for developers of detection tools.

Software metrics provide basic means to quantify quality of software systems. However, the effectiveness of the measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to know, for instance, whether a given metric value indicates a potential problem in a class implementation. There are several methods proposed in literature to derive thresholds for software metrics. However, most of these methods (i) do not respect the skewed distribution of software metrics and (ii) do not provide a supporting tool. Aiming to fill the second gap, we propose a tool, called TDTool, to derive metric thresholds. TDTool is open source and supports four different methods for threshold derivation. This paper presents TDTool architecture and illustrates how to use it. It also presents the thresholds derived using each method based on a benchmark of 33 software product lines.

Online courses are a method of lecturing whose application in education is not bounded by space and location constraints. They include features such as video lectures and online questionnaires. There are a few online courses to teach subjects related to Software Engineering. However, for the best of our knowledge, there is no online course to teach software process, which is a key area of Software Engineering. More important, there is no systematic study to investigate whether this way of teaching is efficient and viable to teach software process. This paper presents an empirical study to evaluate whether and how online features support the learning of software process in the light of an online Software Engineering course with 61 video lectures, 16 online questionnaires, and a discussion forum. This study relies on data of 100 undergraduate students over three consecutive years: 2014, 2015, and 2016. Data of this study suggest that students answer online questionnaires in order to review for face-to-face exams. Our results also show that videos and online questionnaires contribute to the improvement of up to 15% of student grades in software process questions when compared with students who neither watch videos nor answer online questionnaires. However, based on two exam questions that repeated over the three years, we verify that the grade improvement seems to be mostly related to video lectures watched, rather than to online questionnaires answered.