The remaining part of the thesis is organized as follows:
Summary (Part I):Chapter 2 gives an introduction to code smells and software main-
tainability, alongside a description of the current state of research in code smells. Chapter 3 describes and motivates the methodology applied in this study. Chapter 4 summarizes the answers to the research questions, discusses the implications of the results, presents the limitations of the thesis work, provides recommendations for improvements, and offers directions for future research. Chapter 5 summarizes the research.
Papers (Part II): This part includes the six papers of the thesis. Brief descriptions
of the maintainability perspective involved in the papers, the aim of the papers, and the roles of the authors in the work leading to the papers are presented below, alongside the abstracts for each of the papers.
Paper 1: Code Smells as System-level Indicators of Maintainability: An Em- pirical Study
A. Yamashita and S. Counsell
Submitted to Journal of Systems and Software, 2012
Paper 1 addresses thesystem-level perspective of software maintainability. The aim of the study is to evaluate the suitability of code smells for conducting system-level main- tainability assessments. Bente Anda and Dag Sjøberg provided the idea for this work. I participated in the planning of the study in close collaboration with Bente Anda, and was the main responsible for the execution of the study, and the collection of the entire dataset. I conducted the analysis and the writing of the article. I worked in close collab- oration with Steve Counsell during the analysis and writing process of the article. Abstract: Code smells are manifestations of design flaws that can degrade code main- tainability if left to fester. The research in this paper investigates the potential of code smells to reflect system-level indicators of maintainability. We report a study where the strengths and limitations of code smells are evaluated against existing evaluation ap- proaches. We evaluated four medium-sized Java systems using code smells and compared the results against previous evaluations on the same systems based on expert judgment and the Chidamber and Kemerer suite of metrics. The systems were maintained over a period up to 4 weeks. During maintenance, effort (person-hours) and number of defects were measured, to validate the different evaluation approaches. Results suggest that code
smells are strongly influenced by size. An implication is that code smells are likely to yield inaccurate results when comparing the maintainability of systems differing in size. When comparing the evaluation approaches, expert judgment was found as the most accurate and flexible since it considered effects due to a system’s size and complexity and could adapt to different maintenance scenarios. We also found that code smells complemented expert-based evaluation, since they can identify critical code that experts can sometimes overlook.
Paper 2: Quantifying the Effect of Code Smells on Maintenance Effort
D.I.K. Sjøberg, A. Yamashita, B. Anda, A. Mockus, and T. Dybå Submitted to IEEE Transactions on Software Engineering, 2012
Paper 2 addresses the file-level perspective of software maintainability, in contrast to the system-level perspective addressed by Paper 1. The aim of the study is to determine the quantifiable effects of twelve code smells on maintenance effort at file-level, through multiple regression analysis. Dag Sjøberg provided the idea for this work. I participated in the planning of the study in close collaboration with Bente Anda, and was the main responsible for the execution of the study and the collection of the majority of the dataset. I also conducted the summarization and initial analysis of the data. Dag Sjøberg took the lead in the further analysis and the writing of the article, and Audris Mockus con- tributed with the data analysis. The other authors contributed in the writing process. I contributed in the writing process, and was responsible of several sections of the paper. Abstract: Context: Code smells are assumed to indicate bad design that leads to less maintainable code. However, this assumption has not been investigated in controlled studies with professional software developers. Aim: Our aim was to investigate the re- lationship between code smells and maintenance effort. Method: Six developers were hired to perform three maintenance tasks each on four functionally equivalent Java sys- tems originally implemented by different companies. Each developer spent three to four weeks. In total, they modified 298 Java files in the four systems. An Eclipse IDE plug-in measured the exact amount of time a developer spent maintaining each file. A regres- sion was used to explain the effort using file properties, including the number of smells.
Results: None of the 12 investigated smells was significantly associated with increased
effort after we adjusted for file size and the number of changes; Refused Bequest was sig- nificantly associated with decreased effort. File size and the number of changes explained most of the variation in effort. Conclusion: The effects of code smells on maintenance effort are limited. In general, to reduce maintenance effort, focusing on code size and the
work practices that limit the number of changes may be more beneficial than refactoring code smells.
Paper 3: Assessing the Capability of Code Smells to Explain Maintenance Problems: An Empirical Study Combining Quantitative and Qualitative Data
A. Yamashita
Submitted to Journal of Empirical Software Engineering, 2012
Paper 3 addresses, as Paper 2, thefile-level perspective of software maintainability. In- stead of focusing oneffort as in Paper 2, the aim is to investigate the likelihood of a file beingproblematicduring maintenance. I participated in the planning of the study in close collaboration with Bente Anda, and participated in the collection of the entire dataset. I provided the idea for the type of analysis for this paper, and carried out the analysis and writing of the paper. During the analysis and writing process, I received guidance from Magne Jørgensen, and received suggestions from Erik Arisholm.
Abstract: Code smells are indicators of deeper design problems that may cause diffi- culties in the evolution of a software system. This paper investigates the capability of twelve code smells to reflect actual maintenance problems. Four medium-sized systems with equivalent functionality but dissimilar design were examined for code smells. Three change requests were implemented on the systems by six software developers, each of them working for up to four weeks. During that period, we recorded problems faced by developers and the associated Java files on a daily basis. We developed a binary logistic regression model, with “problematic file” as the dependent variable. Twelve code smells, file size, and churn constituted the independent variables. We found that violation of the Interface Segregation Principle (a.k.a. ISP Violation) displayed the strongest connection with maintenance problems. Analysis of the nature of the problems, as reported by the developers in daily interviews and think-aloud sessions, strengthened our view about the relevance of this code smell. We observed, for example, that severe instances of problems related to change propagation were associated with ISP Violation. Based on our results, we recommend that code with ISP Violation should be considered potentially problematic and be prioritized for refactoring.
Paper 4: To What Extent can Maintenance Problems be Predicted by Code Smell Detection? – An Empirical Study
A. Yamashita and L. Moonen
Paper 4 addresses the system-level perspective of maintainability, but instead of observ- ing the effort and defects at system level as in Paper 1, it focuses on the incidence of problems during the maintenance work. The aim is to investigate the role of code smells on the overall maintainability of a system by determining the proportion of maintenance problems with a connection to source code, and more specifically, the proportion of source code related maintenance problems connected to files that contain any of the twelve code smells investigated. My contributions in this paper are the same as described for Paper 3, and I worked in close collaboration with Leon Moonen during the analysis and the writing process.
Abstract: Context: Code smells are indicators of poor coding and design choices that can cause problems during software maintenance and evolution. Objective: This study is aimed at a detailed investigation to which extent problems in maintenance projects can be predicted by the detection of currently known code smells. Method: A multiple case study was conducted, in which the problems faced by six developers working on four different Java systems were registered on a daily basis, for a period up to four weeks. Where applicable, the files associated to the problems were registered. Code smells were detected in the pre-maintenance version of the systems, using the tools Borland Together and InCode. In-depth examination of quantitative and qualitative data was conducted to determine if the observed problems could be explained by the detected smells. Results:
From the total set of problems, roughly 30% percent were related to files containing code smells. In addition, interaction effects were observed amongst code smells, and between code smells and other code characteristics, and these effects led to severe problems dur- ing maintenance. Code smell interactions were observed between collocated smells (i.e., in the same file), and between coupled smells (i.e., spread over multiple files that were coupled). Conclusions: The role of code smells on the overall system maintainability is relatively minor, thus complementary approaches are needed to achieve more comprehen- sive assessments of maintainability. Moreover, to improve theexplanatory power of code smells, interaction effects amongst collocated smells and coupled smells should be taken into account during analysis.
Paper 5: Do Code Smells Reflect Important Maintainability Aspects?
A. Yamashita and L. Moonen
Accepted for publication at the International Conference of Software Maintenance, 2012 Paper 5 aims at determining therelevanceof current code smell definitions for evaluating
maintainability characteristics deemed as essential by software developers. This study investigates the conceptual relatedness between the current definitions of code smells, including those with no automated detection strategies available, and a set of maintain- ability characteristics deemed as critical by software developers. My contributions in this paper are the same as described for Paper 4, and I worked in close collaboration with Leon Moonen during the analysis and the writing process.
Abstract: Code smells are manifestations of design flaws that can degrade code maintain- ability. As such, the existence of code smells seems an ideal indicator for maintainability assessments. However, to achieve comprehensive and accurate evaluations based on code smells, we need to know how well they reflect factors affecting maintainability. After iden- tifying which maintainability factors are reflected by code smells and which not, we can use complementary means to assess the factors that are not addressed by smells. This pa- per reports on an empirical study that investigates the extent to which code smells reflect factors affecting maintainability that have been identified as important by programmers. We consider two sources for our analysis: (1) expert-based maintainability assessments of four Java systems before they entered a maintenance project, and (2) observations and interviews with professional developers who maintained these systems during 14 working days and implemented a number of change requests.
Paper 6: Using Concept Mapping for Maintainability Assessments
A. Yamashita, B. Anda, D.I.K. Sjøberg, H.C. Benestad, P.E. Arnstad and L. Moonen In Proceedings of the 3rd International Symposium of Empirical Software Engineering and Measurement, 2009
Paper 6 describes how concept mapping can be used as a structured approach to com- bine code smell analysis and expert judgment. I provided the initial idea for the paper, conducted the evaluation, and led the writing process of the paper. The other authors participated in the evaluation and contributed in the writing process of the paper. Abstract: Many important phenomena within software engineering are difficult to define and measure. A good example is software maintainability, which has been the subject of considerable research and is believed to be a critical determinant of total software costs. Yet, there is no common agreement on how to describe and measure software maintain- ability in a concrete setting. We propose using concept mapping, a well-grounded method used in social research, to operationalize this concept according to a given goal and per- spective. We apply this method to describe four systems that were developed as part of
an industrial multiple-case study. The outcome is a conceptual map that displays an ar- rangement of maintainability constructs, their interrelations and corresponding measures. Our experience is that concept mapping (1) provides a structured way of combining static code analysis and expert judgment; (2) helps tailoring the choice of measures to a par- ticular system context; and (3) supports the mapping between software measures and aspects of software maintainability. As such, it represents a strong addition to existing frameworks for evaluating quality such as ISO/IEC 9126 and GQM, and tools for static measurement of software code. Overall, we find that concept mapping provides a sys- tematic, structured and repeatable method for developing constructs and measures of the phenomenon of interest, and we deem it useful for defining constructs and measures of other aspects of software engineering, in addition to maintainability.
Background
This chapter introduces and elaborates on the two core concepts in this dissertation: code smells and software maintainability.
2.1
Definition of Code Smells and Its Relevance on
Software Design
Code smells were introduced as indicators of software design shortcomings that can po- tentially decrease software maintainability. Beck and Fowler provided a set of informal descriptions of 22 code smells and associated them with different refactoring strategies that can be applied to improve software design [40, Ch. 3]. These code smells and the associated refactoring strategies are summarized in Tables 2.1, 2.2, and 2.3. As indicated in Ref. [40], a code smell is a potentially poor design choice that can degrade essential aspects of code quality, such as understandability and changeability.
A basic example of a code smell and a potential refactoring to improve a design is given in Figure 2.1. The code smellLong Parameter Listmay reduce readability (e.g., it could be hard to read too many parameters at a time) and modifiability (e.g., it could demand time-consuming changes if the methods are called often). This code smell may also make developers introduce defects because a developer is more prone to make mistakes when the number of parameters in a method call is high. This code smell can be eliminated by applying theIntroduce Parameter Objectrefactoring, which consists in creating a new class containing the parameters of the method and passing the new class as the parameter instead.
Code smells have become an established concept for patterns or aspects of software design that may cause problems in the further development and maintenance of the sys- tem [40, 72, 99]. As such, they have been suggested as better indicators of code quality
getAddress(Address) setAddress(Address)
Person getAddress(street, postcode, country)
setAddress(street, postcode, country) Person
Figure 2.1: Basic example of the elimination of the code smell Long Parameter List by applying the Introduce Parameter Object refactoring strategy.
than traditional object-oriented (OO) metrics. Alshayeb et al. [5] indicated that one of the biggest limitations of traditional OO metrics is their lack ofconcrete strategies (e.g., “knobs”) to influence software design positively. From that perspective, code smells have an advantage because each code smell has a specific set of refactoring strategies to im- prove the design. Consequently, code smells are potentially useful not only for prognosis purposes, but also for improving the quality of the code by associating design problems with concrete solution plans using different refactoring strategies.
Code smells and their refactoring strategies are closely related to OO design principles, heuristics, and patterns. Instances of OO design principles and heuristics can be found in the work by Riel [125] and Coad and Yourdon [24]. Additional work on OO design, which describes concepts such as modularity, information hiding, and open implementation, can be found in Refs. [112, 78, 94, 67]. Work on design patterns (and anti-patterns) can be found in Refs. [19, 42, 73]. Hoss and Carver [57] presented an ontology describing the relationship between anti-patterns and code smells. Martin [90] elaborated on a set of design principles advocated by the Agile community (see Table 2.4).
There has been a growing interest in the topic of code smells for software maintain- ability assessments since the textbook on code smells by Fowler [40] was published in 1999. Van Emden and Moonen [146] provided the first formalization of code smells and described a tool for Java programs. Mäntylä et al. [84] and Wake [147] proposed two initial taxonomies for code smells. The following subchapters describe the different de- tection methods developed for code smells and briefly summarize the results of empirical studies on code smells.
Table 2.1: Code smells in [40] and suggested refactoring strategies. (Part 1)
Smells Descriptions Suggested Refactoring
Strategies
Alternative Classes with Different Interfaces
Classes that mostly do the same things, but have meth- ods with different signatures
Rename Method Move Method Extract Superclass
Data Class Classes with fields and getters and setters not impleme-
nting any function in particular
Encapsulate Field Encapsulate Collection Remove Setting Method Move Method Extract Method Hide Method
Data Clumps Clumps of data items that are always found together
weather within classes or between classes
Extract Class
Introduce Parameter Object Preserve Whole Object
Divergent Change One class is commonly changed in different ways for dif-
ferent reasons
Extract Class
Duplicated Code Same or similar code structure repeated within a class
or between classes
Extract Method Pull Up Method Form Template Method Substitute Algorithm
Feature Envy
A method that seems more interested in another class other than the one it’s actually in. Fowler recommends putting a method in the class that contains most of the data the method needs.
Move Method Extract Method
God (Large) Class
A class has the God Class smell if the class takes too many responsibilities relative to the classes with which it is coupled. The God Class centralizes the system fun- ctionality in one class, which contradicts the
decomposition design principles.
Extract Class Extract Subclass Extract Interface Duplicate Observed Data
God (Long) Method
A class has the God Method bad smell if at least one of its methods is very large compared to the other methods in the same class. God Method centralizes the class functionality in one method
Extract Method Replace Temp with Query Introduce Parameter Object Preserve Whole Object
Replace Method with
Method Object Decompose Conditional
Table 2.2: Code smells in [40] and suggested refactoring strategies. (Part 2)
Smells Descriptions Suggested Refactoring
Strategies
Inappropriate Intimacy Two classes are overly intertwined
Move Method Move Field
Change Bidirectional Associ- ation to Unidirectional Extract Class Hide Delegate
Replace Inheritance with
Delegation
Incomplete library class Libraries lacking on specific functionality Introduce Foreign Method