Context: During the last years, developers of mobile applications have the possibility to use new paradigms and tools for developing mobile applications. For instance, since 2017 Android developers have the official support to write Android applications using Kotlin language. Kotlin is programming language fully interoperable with Java that combines object-oriented and functional features. Objective: The goal of this paper is twofold. First, it aims to study the degree of adoption of Kotlin language on development of open-source Android applications and to measure the amount of Kotlin code inside Android applications. Secondly, it aims to measure the quality of Android applications that are written using Kotlin and to compare it with the quality of Android applications written using Java. Method: We first defined a method to detect Kotlin applications from a dataset of open-source Android applications. Then, we analyzed those applications to detect instances of code smells and computed an estimation of quality of the applications. Finally, we studied how the introduction of Kotlin code impacts on the quality of an Android application. Results: Our experiment found that 11.26 of applications from a dataset with 2,167 open-source applications have been written (partially or fully) using Kotlin language. We found that the introduction of Kotlin code increases the quality (in terms of presence of code smells) of the majority of the Android applications initially written in Java.
Kent Beck coined the term in the context of identifying quality issues in code that can be refactored to improve the maintainability of a software . Since there, the software engineering community has explored various associated dimensions that include proposing a catalog of smells, detecting smells using a variety of techniques, exploring the relationships among smells, and identifying the causes and effects of smells . However, according to @cite_23 , traditional code smells capture very general principles of good design. Moreover, they suggested that specific types of code smells are needed to capture bad practices'' on software systems based on a specific platform, architecture or technology. In this context, it possible to find work focused on smells specific to the usage of object-relational mapping frameworks , Android applications , Cascading Style Sheets (CSS) and Model View Controller (MVC) Architecture .
@cite_23
2149963636 2801519434 2532677196 2023128682
Refactoring can have a direct influence on reducing the cost of software maintenance through changing the internal structure of the source-code to improve the overall design that helps the present and future programmers evolve and understand a system. Bad smells are a set of design problems with refactoring identified as a solution. Locating these bad smells has been described as more a human intuition than an exact science. This paper addresses the issue of identifying the characteristics of a bad smell through the use of a set of software metrics. Then by using a pre-defined set of interpretation rules to interpret the software metric results applied to Java source-code, the software engineer can be provided with significant guidance as to the location of bad smells. These issues are addressed in a number of ways. Firstly, a precise definition of bad smells is given from the informal descriptions given by the originators Fowler and Beck. The characteristics of the bad smells have been used to define a set of measurements and interpretation rules for a subset of the bad smells. A prototype tool has been implemented to enable the evaluation of the interpretation rules in two case studies. Code smells and architectural smells (also called bad smells) are symptoms of poor design that can hinder code understandability and decrease maintainability. Several bad smells have been defined in the literature for both generic architectures and specific architectures. However, cloud-native applications based on microservices can be affected by other types of issues. In order to identify a set of microservice-specific bad smells, researchers collected evidence of bad practices by interviewing 72 developers with experience in developing systems based on microservices. Then, they classified the bad practices into a catalog of 11 microservice-specific bad smells frequently considered harmful by practitioners. The results can be used by practitioners and researchers as a guideline to avoid experiencing the same difficult situations in the systems they develop. Software decay is a phenomenon that plagues aging software systems. While in recent years, there has been significant progress in the area of automatic detection of "code smells" on one hand, and code refactorings on the other hand, we claim that existing restructuring practices are seriously hampered by their symptomatic and informal (non-repeatable) nature. This paper makes a clear distinction between structural problems and structural symptoms (also known as code smells), and presents a novel, causal approach to restructuring object oriented systems. Our approach is based on two innovations: the encapsulation of correlations of symptoms and additional contextual information into higher-level design problems, and the univocal, explicit mapping of problems to unique refactoring solutions. Due to its explicit, repeatable nature, the approach shows high potential for increased levels of automation in the restructuring process, and consequently a decrease in maintenance costs. Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO IEC IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.