Improving Software Design by Mitigating Code Smells

Introduction

Typically, the legacy and large-scale software systems have long term evolutions/ maintenance phase for incorporating new features, bug removal, requirement change, etc. (Lehman & Belady, 1985). These long-term maintenance activities and/ or poor programming skills may result in the introduction of poor design symptoms and implementation choices. Such poor symptoms which are commonly known as code smells may cause a problem with the future evolution, adaptation, increased fault-proneness or hinders the comprehensibility of the software system (Lanza & Marinescu, 2007). Therefore, it is very much important to regularly monitor the evolution of a software system and to correctly identify such code smells. Further appropriate actions (commonly termed as refactoring) should be taken to remove these code smells (Fowler, 2018).

The refactoring steps for improving the quality of software are well defined by (Fowler, 2018). However, there is always a challenge for the appropriate mechanism for detecting various code smells. Determining such a mechanism is always time-consuming and non-trivial activity (Ligu et al., 2013). In an object-oriented development paradigm, inheritance is a tested phenomenon that often helps in reducing maintenance. However, sometimes inheritance is confused with other forms of relations (such as an association) and in such cases, it may inappropriately degrade the quality of the software system. Such a confusing situation is commonly termed as a refused bequest code smell. Many approaches are proposed in the literature to handle refused bequest code smell (Ligu et al., 2013; Li & Shatnawi, 2007, Merzah & Selçuk, 2017; Palomba et al., 2018). All of these approaches are based on some combination of trivial Cyclomatic/ Inheritance metrics (Li & Shatnawi, 2007, Merzah & Selçuk, 2017; Palomba et al., 2018) or measuring different code smell intensity factors (Ligu et al., 2013). However, such trivial metrics do not generally capture every dimension related to refused code smell and often ignores the human perception about the refused bequest code smell. Another key design flaw is termed as shotgun surgery and it represents the low-level complicated coupling among classes that may cause series of subsequent, necessary changes in response to the change in any one of the involved coupled class. In literature, many approaches are already proposed that are solely based on either the use of change history and trivial code based metrics (Palomba et al., 2013; Abílio et al., 2015; Li & Shatnawi, 2007; Olbrich et al., 2009). Such approaches lack in utilizing important function-based coupling among classes and do not tests the feasibility of combined use of change history with other code-based metrics. One more serious issue that causes increased maintenance and size is known as duplicated code/ code clones and it involves copy-pasting fragments of source code at many places in the software in order to promote reuse opportunities. Many close approaches that focus on detecting duplicated code smell involves (Jiang et al., 2007; Fu & Shen, 2015; Liu & Zhang, 2018). Roy et al. classified code clones into four categories (Roy et al., 2009). The existing approaches are either token-based, semantics-based, string-based, or tree-based. However, such approaches are not robust enough against code modifications i.e. they either do not detect type-4 (logical modifications) or they show very little efficiency.