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

Towards the Detection of UX Smells: The Support of Visualizations

Daily experiences in working with various types of computer systems show that, despite the offered functionalities, users have many difficulties, which affect their overall User eXperience (UX). The UX focus is on aesthetics, emotions and social involvement, but usability has a great influence on UX. Usability evaluation is acknowledged as a fundamental activity of the entire development process in software practices. Research in Human-Computer Interaction has proposed methods and tools to support usability evaluation. However, when performing an evaluation study, novice evaluators still have difficulties to identify usability problems and to understand their causes: they would need easier to use and possibly automated tools. This article describes four visualization techniques whose aim is to support the work of evaluators when performing usability tests to evaluate websites. Specifically, they help detect "usability smells", i.e. hints on web pages that might present usability problems, by visualizing the paths followed by the test participants when navigating in a website to perform a test task. A user study with 15 participants compared the four techniques and revealed that the proposed visualizations have the potential to be valuable tools for novice usability evaluators. These first results should push researchers towards the development of further tools that are capable to support the detection of other types of UX smells in the evaluation of computer systems and that can be translated into common industry practices

Towards Usable API Documentation

The learning and usage of an API is supported by documentation. Like source code, API documentation is itself a software product. Several research results show that bad design in API documentation can make the reuse of API features difficult. Indeed, similar to code smells, poorly designed API documentation can also exhibit 'smells'. Such documentation smells can be described as bad documentation styles that do not necessarily produce incorrect documentation but make the documentation difficult to understand and use. This thesis aims to enhance API documentation usability by addressing such documentation smells in three phases. In the first phase, we developed a catalog of five API documentation smells consulting literature on API documentation issues and online developer discussion. We validated their presence in the real world by creating a benchmark of 1K official Java API documentation units and conducting a survey of 21 developers. The developers confirmed that these smells hinder their productivity and called for automatic detection and fixing. In the second phase, we developed machine-learning models to detect the smells using the 1K benchmark, however, they performed poorly when evaluated on larger and more diverse documentation sources. We explored more advanced models; employed re-training and hyperparameter tuning to further improve the performance. Our best-performing model, RoBERTa, achieved F1-scores of 0.71-0.93 in detecting different smells. In the third phase, we first focused on evaluating the feasibility and impact of fixing various smells in the eyes of practitioners. Through a second survey of 30 practitioners, we found that fixing the lazy smell was perceived as the most feasible and impactful. However, there was no universal consensus on whether and how other smells can/should be fixed. Finally, we proposed a two-stage pipeline for fixing lazy documentation, involving additional textual description and documentation-specific code example generation. Our approach utilized a large language model, GPT- 3, to generate enhanced documentation based on non-lazy examples and to produce code examples. The generated code examples were refined iteratively until they were error-free. Our technique demonstrated a high success rate with a significant number of lazy documentation instances being fixed and error-free code examples being generated

Understanding automated and human-based technical debt identification approaches-a two-phase study

Context: The technical debt (TD) concept inspires the development of useful methods and tools that support TD identification and management. However, there is a lack of evidence on how different TD identification tools could be complementary and, also, how human-based identification compares with them. Objective: To understand how to effectively elicit TD from humans, to investigate several types of tools for TD identification, and to understand the developers’ point of view about TD indicators and items reported by tools. Method: We asked developers to identify TD items from a real software project. We also collected the output of three tools to automatically identify TD and compared the results in terms of their locations in the source code. Then, we collected developers’ opinions on the identification process through a focus group. Results: Aggregation seems to be an appropriate way to combine TD reported by developers. The tools used cannot help in identifying many important TD types, so involving humans is necessary. Developers reported that the tools would help them to identify TD faster or more accurately and that project priorities and current development activities are important to be considered together, along with the values of principal and interest, when deciding to pay off a debt. Conclusion: This work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered

A Generic Technique for Domain-Specific Visual Language Model Refactoring to Patterns

As the popularity of domain-specific visual languages (DSVLs) grows, concerns have arisen regarding quality assurance and evolvability of their meta-models and model instances. In this paper we address aspects of automated DSVL model instance modification for quality improvement based on refactoring specifications. We propose a graph transformation-based visual language approach for DSVL authors to specify the matching and discovery of DSVL “bad model smells” and the application of pattern-based solutions in a DSVL meta-tool. As an outcome, DSVL users are provided with pattern-based design evolution support as refactorings for their DSVL-based domain models

Improving software quality using an ontology-based approach

Ensuring quality in software development is a challenging process. The concepts of anti-pattern and bad code smells utilize the knowledge of reoccurring problems to improve the quality of current and future software development. Anti-patterns describe recurring bad design solutions while bad code smells describe source code that is error-free but difficult to understand and maintain. Code refactoring aims to remove bad code smells without changing a program’s functionality while improving program quality. There are metrics-based tools to detect a few bad code smells from source code; however, the knowledge and understanding of these indicators of low quality software are still insufficient to resolve many of the problems they represent. Minimal research addresses the relationships between or among bad code smells, anti-patterns and refactoring. In this research, we present a new ontology, Ontology for Anti-patterns, Bad Code Smells and Refactoring (OABR), to define the concepts and their relation properties. Such an ontological infrastructure encourages a common understanding of these concepts among the software community and provides more concise definitions that help to avoid overlapping and inconsistent description. It utilizes reasoning capabilities associated with ontology to analyze the software development domain and offer new insights into the domain. Software quality issues such as understandability and maintainability can be improved by identifying and resolving anti-patterns associated with code smells as well as preventing bad code smells before coding begins

EMPIRICAL ASSESSMENT OF THE IMPACT OF USING AUTOMATIC STATIC ANALYSIS ON CODE QUALITY

Automatic static analysis (ASA) tools analyze the source or compiled code looking for violations of recommended programming practices (called issues) that might cause faults or might degrade some dimensions of software quality. Antonio Vetro' has focused his PhD in studying how applying ASA impacts software quality, taking as reference point the different quality dimensions specified by the standard ISO/IEC 25010. The epistemological approach he used is that one of empirical software engineering. During his three years PhD, he's been conducting experiments and case studies on three main areas: Functionality/Reliability, Performance and Maintainability. He empirically proved that specific ASA issues had impact on these quality characteristics in the contexts under study: thus, removing them from the code resulted in a quality improvement. Vetro' has also investigated and proposed new research directions for this field: using ASA to improve software energy efficiency and to detect the problems deriving from the interaction of multiple languages. The contribution is enriched with the final recommendation of a generalized process for researchers and practitioners with a twofold goal: improve software quality through ASA and create a body of knowledge on the impact of using ASA on specific software quality dimensions, based on empirical evidence. This thesis represents a first step towards this goa

Ant Build Maintenance with Formiga

A build system produces a set of deliverables from a software project\u27s source code and resources. Build maintenance refers to the changes made to the build system as a software project evolves over time. It has been shown to impose a significant overhead on overall development costs, in part because changes to source code often require parallel changes in the build system. However, little tool support exists to assist developers with build maintenance, particularly for those changes that must accompany changes to the source code. Formiga is a build maintenance and dependency discovery tool for the Ant build system. Formiga\u27s primary uses are to automate build changes as the source code is updated, to identify the build dependencies within a software project, and to assist with build refactoring. Formiga is implemented as an IDE plugin, which allows it to recognize when project resources are updated and automatically update the build system accordingly. This implementation also allows it to leverage existing metaphors used by developers to maintain source code, thus making it easier to use. A controlled experiment was conducted to assess Formiga\u27s ability to assist developers with build maintenance. Formiga was shown to signficantly reduce the time required to perform build maintenance while increasing the correctness with which it can be performed