Code smells for Model-View-Controller architectures

Abstract

Previous studies have shown the negative effects that low-quality code can have on maintainability proxies, such as code change-and defect-proneness. One of the symptoms of low-quality code are code smells, defined as sub-optimal implementation choices. While this definition is quite general and seems to suggest a wide spectrum of smells that can affect software systems, the research literature mostly focuses on the set of smells defined in the catalog by Fowler and Beck, reporting design issues that can potentially affect any kind of system, regardless of their architecture (e.g., Complex Class). However, systems adopting a specific architecture (e.g., the Model-View-Controller pattern) can be affected by other types of poor practices that only manifest themselves in the chosen architecture. We present a catalog of six smells tailored to MVC applications and defined by surveying/interviewing 53 MVC developers. We validate our catalog from different perspectives. First, we assess the relationship between the defined smells and the code change-and defect-proneness. Second, we investigate when these smells are introduced and how long they survive. Third, we survey 21 developers to verify their perception of the defined smells. Fourth, since our catalog has been mainly defined together with developers adopting a specific Java framework in their MVC applications (e.g., Spring), we interview four expert developers working with different technologies for the implementation of their MVC applications to check the generalizability of our catalog. The achieved results show that the defined Web MVC smells (i) more often than not, have more chances of being subject to changes and defects, (ii) are mostly introduced when the affected file (i.e., the file containing the smell) is committed for the first time in the repository and survive for long time in the system, (iii) are perceived by developers as severe problems, and (iv) generalize to other languages/frameworks.

9.6 Million Links in Source Code Comments: Purpose, Evolution, and Decay

“…The required sample size was calculated so that our conclusions about the ratio of links with a specific characteristic would generalize to all links in the same bucket with a confidence level of 95% and a confidence interval of 5. 4 The calculation of statistically significant sample sizes based on population size, confidence interval, and confidence level is well established (first published by Krejcie and Morgan in 1970 [19]).…”

Current Challenges in Practical Object-Oriented Software Design

“…Current solutions: Taking into consideration the domain and the architecture of the system under study has been gaining attention from the community in the last years. Although linters are widely used [35], [36], and quality monitoring strategies such as Continuous Inspection have been proposed [26], researchers have shown that the domain of the application matters when it comes to the presence of code smells [22], that code metric distributions are statistically different among the different architectural roles of classes in a system [3], [23], and that specific architectures may have their own specific smells [2], [19].…”

User interface design smell: Automatic detection and refactoring of Blob listeners

“…Aniche et al define several design smells that affect web applications [9]. In particular, a design smell focuses on web controllers that bind the model (on the server side) and the UI (on the client side) of the application.…”

“…These smells are described in Table 9. Several of them (UI Shotgun Surgery, UI Middle Man, UI Inappropriate Intimacy, and UI Feature Envy) are adaptations of the object-oriented design smells of [26] Strategy [25] Blob Listener A UI listener/handler that controls too Implementation Deficient encapsulation Metric-based much interactive objects Promiscuous Controller [9] web server-side controllers that Design and Weakened modularity Metric-based manage too many routes Implementation Brain Controller [9] Server-side controllers that do too much Design and Weakened modularity Metric-based (lack of separation of concern) Implementation UI Shotgun Surgery [27] A change on the UI structure spans over Usability N/A None multiple UI implementations Too Many Layers [27] A UI is composed of too many Usability N/A None layers (e.g., windows) UI Middle Man [27] A UI component (e.g., a window) delegates Usability N/A None the job to another UI component Information Overload [27] Too much information is provided to users Usability N/A None UI Inappropriate Intimacy [27] Several UIs, accessible from different places, Usability N/A None handle related domain elements UI Feature Envy [27] One UI allows user to perform a task also Usability N/A None provided by another UI of the system the same name [11] with a focus on UI code. The Too Many Layers and Information Overload UI design smells are related to the structural complexity of UIs that may have a negative impact on their understanding by users.…”