# Predicting the Impact of Batch Refactoring Code Smells on Application
Resource Consumption

Asif Imran  ,  Tevfik Kosar  ,  Jaroslaw Zola  and  Fatih Bulut

###### Abstract.

Background: Automated batch refactoring has become a de-facto mechanism to
restructure software that may have significant design flaws negatively
impacting the code quality and maintainability. Although automated batch
refactoring techniques are known to significantly improve overall software
quality and maintainability, their impact on resource utilization is not well
studied.
Aims: This paper aims to bridge the gap between batch refactoring code smells
and consumption of resources. It determines the relationship between software
code smell batch refactoring, and resource consumption. Next, it aims to
design algorithms to predict the impact of code smell refactoring on resource
consumption.
Method: This paper investigates 16 code smell types and their joint effect on
resource utilization for 31 open source applications. It provides a detailed
empirical analysis of the change in application CPU and memory utilization
after refactoring specific code smells in isolation and in batches. This
analysis is then used to train regression algorithms to predict the impact of
batch refactoring on CPU and memory utilization before making any refactoring
decisions.
Results: Experimental results also show that our ANN-based regression model
provides highly accurate predictions for the impact of batch refactoring on
resource consumption. It allows the software developers to intelligently
decide which code smells they should refactor jointly to achieve high code
quality and maintainability without increasing the application resource
utilization.
Conclusion: This paper responds to the important and urgent need of software
engineers across a broad range of software applications, who are looking to
refactor code smells and at the same time improve resource consumption.
Finally, it brings forward the concept of resource aware code smell
refactoring to the most crucial software applications.

code smells, software batch refactoring, software resource consumption.

##  1\. Introduction

Modern software development practices suffer from increased pressure to
deliver new features in a shorter time to meet the deadlines and compete with
peers. Collaborative codebases with a large number of contributors who may
have different levels of expertise and coding standards and continuously
evolving software without a proper design add to the problem. These practices
generally result in code smells, a software behavior that indicates a
violation of fundamental design principles and negatively impacts the code’s
readability, maintainability, and scalability (Fowler, 2018). Certain types of
code smells may also drain system resources like CPU and memory, resulting in
wastage of critical resources, increasing the cost of operating the software,
and even degrading the performance of the applications in some cases (Pérez-
Castillo and Piattini, 2014). For example, the cyclic dependency code smell
violates the acyclic properties of code and introduces loops where it may not
be necessary. The enhanced loops will cause repetition of a process in the
execution flow and result in excess resource consumption.

Fixing the code smells is known to improve code quality and maintainability,
but it does not always result in better application resource utilization. Some
of the code refactoring techniques and tools used during this process can
introduce other anomalies that can increase the application’s CPU and memory
utilization (Holzer et al., 2009). The majority of the existing work on
automated code smell refactoring focuses on correctness (Paixão et al., 2020),
maintainability (Vakilian et al., 2012), and scalability (Murphy-Hill, 2008).
Previous research studying the impact of code smell refactoring on resource
consumption is quite limited. Also, in modern software coding, smells are
refactored in groups, and the impact of batch refactoring code smells on
resource consumption requires further exploration (Fernandes, 2019).
Verdecchia et al. (Verdecchia et al., 2018) performed an exploratory analysis
of the impact of code smell refactoring on energy consumption and performance
in software applications. They selected five different code smells (feature
envy, type checking, long method, god class, and duplicated code), which were
automatically detected and refactored in three open-source Java software
applications. Other efforts were limited to the isolated impact of a small
segment of code smells, which did not consider the combined impact of
refactoring a large number of smells (Wang et al., 2014). At the same time,
previous research studies considered only a handful of applications to analyze
the impact (Anwar et al., 2019).

This paper fills a void in this area by providing a comprehensive analysis on
the impact of batch refactoring 16 different code smell types on the resource
consumption of 31 real-life Java and Python applications. We find that batch
refactoring of code smells has a significant impact on both CPU and memory
usage. Depending on the goal of the application developers, this study enables
intelligent selection of which smells should be refactored together and which
ones not be refactored. If the primary goal is easy to maintain code, then all
smells can be refactored. In that case, this study can provide the developers
with an estimation of the expected change in resource utilization after batch
refactoring. If the concern is not only easy maintenance but also resource
consumption of the application, this study will help the developers to
intelligently decide which smells to refactor jointly to minimize the resource
consumption.

In this study, we used 3 different automated refactoring tools, Jdeodorant
(Fokaefs et al., 2011) and JSparrow (IT-Consulting, 2020) for Java and pycharm
for Python (Gulabovska and Porkoláb, 2019) applications to detect and refactor
the code smells. We establish a benchmark where individual types of code
smells are detected and refactored in each software, followed by an analysis
of CPU and memory consumption impact. Afterward, we conduct a batch
refactoring of smells and analyze their collective impact on resource usage.
Next, we use the benchmark data to predict the impact of batch smell
refactoring on CPU and memory usage. We apply five regression models, namely
linear regression, polynomial regression, lasso regression, random forest, and
ANN regression, and calculate their accuracy using the mean square error (MSE)
and root mean squared error (RMSE) values. Experimental results show that ANN
regression outperforms the other models in terms of prediction accuracy.

The major contributions of this paper include the following:

  * •

A detailed impact analysis of refactoring 16 different code smell types on the
resource consumption of different Java and Python applications.

  * •

An empirical evaluation of the change in resource utilization after auto-
refactoring specific code smells in isolation as well as batch refactoring.

  * •

A set of guiding principles to select the code smells which will improve
resource usage when refactored collectively.

  * •

A mechanism based on regression analysis to predict the impact of batch
refactoring code smells on CPU and memory utilization before making any
refactoring decisions.

The rest of the paper is organized as follows: Section 2 explains the code
smell types, the selected applications, workloads and the automated
refactoring tools used for this study. Section 3 presents the results of the
experiments and a summary of our findings, including the impact of batch
refactoring and regression-based predictive modeling. Section 4 discusses the
related work in this area, and Section 5 concludes the paper.

##  2\. Methodology and Experimental Setup

Our analysis includes 16 different code smell types, and to the best of our
knowledge, this is the most comprehensive study in this area so far. All
selected smells can be detected and refactored using off-the-shelf automated
refactoring tools. Table 1 summarizes the 16 code smells, including their
properties, refactoring techniques, and their impact on application resource
utilization.

Smell Type |  Property |  Refactoring technique |  Impact on Resource Utilization
---|---|---|---
cyclic dependency |  Violates acyclic properties and results in misplaced elements (Sarkar et al., 2012) |  Encapsulating all packages in a cycle and assign to single team |  Refactoring prevents the enhanced loops from repeating, thus prevents resource wastage
god method |  Many activities in a single method (Fowler, 2018) |  Divide the god method into multiple smaller methods |  Multiple processes in a single method cause less inter-method communication, hence preserves resource usage
spaghetti code |  Addition of new code without removing obsolete ones (Abbes et al., 2011) |  Replace procedural code segments with object oriented design |  Unrefactored code contains length() and size() can have a time complexity of O(n), refactoring results in using isEmpty() instead of length() and size() which has a complexity of O(1)
shotgun surgery |  Single behavior defined across multiple classes(Fowler, 2018) |  Use Move Method and Move Field to move repetitive class behaviors into a single class |  Refactoring removes the resource-consuming code blocks which were applied in multiple locations
god class |  One class aims to do activities of many classes (Fowler, 2018) |  Divide the large class into smaller classes |  Refactoring causes greater inter-class communication, thus increasing resource consumption
lazy class |  The class does not do enough activity and can be easily replaced (Fowler, 2018) |  Use diamond operators to remove re-implementation of interface |  Refactoring lazy class prevents the consumption of excess resource due to context switching from this class to the other classes
refused bequest |  When the child classes of a parent are not related in any way, caused mainly by forceful inheritance (Palomba et al., 2019) |  Replace inheritance with delegation |  Restructuring of code due to refactoring removes forceful inheritance, thereby preventing excess resource consumption
temporary field |  When an instance variable is set only for certain cases (Fowler, 2018) |  Remove unnecessary throws and unused parameters |  Refactoring results in removing temporary variables which act as additional fields ad consume CPU and memory in addition to the other variables
speculative generality |  Codes which are placed by programmers for anticipated future events (Samarthyam et al., 2016) |  Eliminate the smell by boxing objects to use static strings. |  As described above boxing the scalars to use the toString method is a waste of memory and CPU cycles.
dead code |  Obsolete code which was not removed (Gamma, 1995) |  Parse through the methods to remove redundant code. |  Code which is no longer needed keeps calling the methods and allocate spaces in memory and consume CPU cycles. Refactoring removes this redundant code, thus stopping resource wastage
duplicate code |  A code block which was copied in multiple classes rather than called through an object (Fowler, 2018) |  Apply proper inheritance |  Removal of duplicate lines of code in multiple places will prevent CPU and memory from wastage
long parameter |  When a method takes more than 5 parameters it is generally called to be having a long parameter (Samarthyam et al., 2016) |  Simplify the lambda using method reference |  Refactoring excessive number of parameters in a method will prevent caching at the beginning and this would remove the extra load on the CPU, however, memory usage will be increased
long statement |  A statement in a code, e.g. a switch statement containing too many cases (Shvets, [n.d.]) |  Divide the long statement into smaller statements and establish proper communication between those. |  Refactoring prevents loading a long statement into memory which would otherwise consume excess memory resources.
primitive obsession |  The undesirable practice of using primitive types when representing an object. (Shvets, [n.d.]) |  Use $StringBuilder$ which ensures that no locking and syncing is done, resulting in faster operation. |  Removes the use of obsolete string manipulation techniques like StringBuffer which allows locking but no synchronization, thereby saving CPU and memory resource
orphan variable |  Variables that should be owned by another member class (Shvets, [n.d.]) |  Extract all the variables to a class that should own them. |  Refactoring ensures that a variable is transferred to a class to which it should belong, thus preventing wastage of CPU cycles and memory spaces while doing this communication
middleman |  When a class is delegating almost all of its functionality to other classes (Shvets, [n.d.]) |  Transfer functionality placed to the classes that they were mediating |  Presence of such a delegation centered class will create extra overhead in terms of resource consumption which is prevented by refactoring
Table 1. Characteristics and refactoring techniques of the analyzed software
smells.

For automated smell detection and refactoring, we used jdeodrant (Fokaefs et
al., 2011) and jsparrow (IT-Consulting, 2020) for Java and pycharm for Python
(Gulabovska and Porkoláb, 2019) applications to detect and refactor the code
smells.

For each application, first, we compile and run the application without
refactoring. In the process, we gather metadata in terms of CPU and memory
usage. Second, we refactor them in two phases: in phase 1, we refactor all
occurrences of one particular type of smell. In phase 2, we refactor multiple
types of smells together to analyze the batch effect. Each application is run
14 times: seven times before refactoring and seven times after refactoring for
each type of smell. We then take the average and standard deviation for the
reported CPU and memory usage numbers. In total, we executed 6300 experimental
runs for this study. Once all data is collected, we find the difference in CPU
and memory usage before and after refactoring. Next, we normalize the
differences in resource usage by the instance of each type of smell that was
detected. This gives us the per smell impact of a specific type for each
application.

For method-level data collection, we use a tool called hprof (O’Hair, 2004).
We record the execution path of the code and note the CPU and memory usage
where the code smells are refactored. This allows us to collect information on
resource usage precisely of the method which is refactored. As a result, we
can relate the change in resource usage to refactoring. This is achieved by
tracking resource usage via method_id which is unique to a method and assigned
by the $hprof$ tool. Using hprof we collect resource usage data every 10 ms.
For Python, we load the source codes in the pycharm and compile the code.
Afterwards, we apply specific workloads to test the resource usage before
refactoring. When the applications are running, we execute the workload and
collect the resource usage using logpid. Next, we refactor the code smells in
the same procedure discussed earlier and re-collect the resource usage data
using the same workload. The workloads and experiments are detailed in the
next section.

We conducted the experiments in cloud virtual machines which were created
using kernel virtual machine (KVM) over a bare metal server. The bare metal
had 32 GB RAM, 8 core processors, and 2 TB persistent storage. We allocated a
single core for every VM to make sure that the parallelization of processes
does not affect the measurements. We ran each application 14 times. Every time
a code smell was refactored, we executed the software in a new clean instance
to eliminate the impact of previous run.

For Java, we have selected 24 open source applications111The list of selected
24 Java applications and their details can be viewed on the GitHub page:
https://github.com/asif33/batchrefactoring/blob/applications/java-apps.png
from Qualitas Corpus (Tempero et al., 2010), which is a dataset of 72 open-
source Java applications. From the Corpus, we identified applications in five
categories: code analyzers, code parsers, editors, email clients, and testing
software. We selected applications which have more than 5000 lines of code
(LoC), with at least 50 contributors in order to eliminate the risk of
considering immature or a few developer contributed applications. For Python,
we selected 7 open source applications222The list of selected 7 Python
applications and their details can be viewed on the GitHub page:
https://github.com/asif33/batchrefactoring/blob/applications/python-
applications.png which have at least 5000 LoC and over 100 contributors. Next
we explain the applications and workloads that were used in our experiments.

###  2.1. Java: Applications and Workloads

For Java applications, in order to understand the impact of refactoring on
resource utilization, following workloads were run (clustered by application
categories):

Email clients. The applications analyzed under this category are emf (Santos
et al., 2020) and columba (Dietz and Stitch, 2017). Predefined email of size
70 bytes were sent using SMTP server (Riungu-Kalliosaari et al., 2011). The
emails were sent to 2920 users who were identified as mail readers. The
average time to deliver an email is 3083.03 milliseconds with a median of
2847.3 milliseconds.

Testing software. Eclipse bug dataset (Zimmermann et al., 2007) is used as a
workload, which contains data about six applications we analyzed in this
category, namely jmeter (Halili, 2008), findbugs (Ayewah et al., 2007),
cobertura (Aarniala, 2005), emma (Liu et al., 2014a), jstock (Tempero et al.,
2010), and pmd (Rutar et al., 2004). We merged all classes and files into one
large dataset which resulted in 24,642 LOC (Anvik et al., 2005). The workload
constituted of demo web services in Java which consisted of Java Server Pages
(JSP), servlets, Enterprise Java Bean, and a database. The applications in the
corpus were responsible for testing every conditionals and loop statements.

Editors. We studied seven applications in this category, which are jedit
(Wenzel, 2012), jhotdraw (Savolskyte, 2004), antlr (Parr and Quong, 1995),
aoi, galleon, batik (Tempero et al., 2010), and jruby (Nutter et al., 2014).
Multiple bots conducted activities in the editor such as typing, loading saved
pictures, drawing simple shapes, and using various editor properties. The
workload of each bot was 9.9 MB and a total of 109 virtual bots were used
(Jacob et al., 2010), (Myers, 1978). The total time for the workload of all
bots was 180 seconds.

Project management. The applications in this category include ganttproject
(Cromar, 2013), xerces (Leung, 2004), javacc (Dos Reis, 2012), nekohtml
(Tempero et al., 2010), log4j (Liu et al., 2014b), and sablecc (Dos Reis,
2012). Multiple bots conducted project management activities (Armbrust et al.,
2009a). Three sample projects was chosen: automated tender and procurement
management, college management system, and resource monitoring system for
ready-made garments. For each of the projects, bots checked whether the
project management tool is available all the time.

Parsers. The applications considered in this category are ant (Tempero et al.,
2010), jparse (James, [n.d.]), and xalan (Leung, 2004). The workload contained
a set of incorrect and correct inputs (Duong et al., 2017), (Ćirić and Rančić,
2005). The incorrect input is fed into the parser and ensured that the correct
error code was returned by the parser. For the correct input, the expected
Abstract Syntax Trees (AST) were described in a format that can be correctly
parsed. The AST of the correct input was verified by a third party XML based
parser considered to be bug free.

###  2.2. Python: Applications and Workloads

For Python applications, in order to evaluate the impact of refactoring on
resource utilization, following applications and workloads were run:

OpenStack. OpenStack is a cloud platform providing the users with virtual
machine instances which can be used for Software as a Service (SaaS), Platform
as a Service (PaaS), or Infrastructure as a Service (IaaS) (Sefraoui et al.,
2012). It is the most popular open source cloud platform in both academia and
industry (Armbrust et al., 2009b). To test the OpenStack source code, we
compiled from source code and launched VM instances. The OpenStack processes
including nova-compute were allocated to a single node and the resource
consumption of that core were monitored.

Sentry. Sentry is a tool which reports and documents exceptions thrown by
Python code russing at the back-end servers. Sentry runs in the background and
acts as a central hub to monitor and report errors. Test case workloads
provided by pytest were used for the experiments. We used the factory helper
method to build data for the workload. The factory methods in
_sentry.testutils.factories_ were available on all our test suite classes and
stated in Sentry. We used the _-k_ option with _pytest_ to put workload on a
single directory, single file, or single test depending on the scope of the
code refactoring.

Tensorflow. To test Tensorflow we use the $tf.distribute.Strategy$ to run the
”2017 US Internal Migration” dataset and train the system. The database
contained 80 years of data and it is used to train the Tensorflow model to
predict the internal migration trend for next 2 years. The size of the dataset
was 3.2 GB large which contained detailed information regarding migration
population, age, gender, occupation and economic conditions.

Tornado. Tornado is a scalable framework with asynchronous networking library,
primarily used to long-lived network applications. For Tornado, the inbuilt
test suite was used to generate the data which will be used as a workload. The
framework is synchronous, so the test results are completed when the method
which is being tested returns.

Rebound. Rebound is a popular tool used by software engineers. It is a command
line tool written in Python that fetches all the solutions from stack overflow
related to a problem. As a workload we called the sim.integrate(100.) function
which presents 100 pre-specified erroneous code blocks in rebound and relies
on it to fetch the solutions from stack overflow.

Kivy. Kivy is a Python library that is built over OpenGL ES 2 that allows
rapid development of multi touch applications. The workload for Kiny was
generated using its own module called recorder, which allowed to replay
keyboard events in a sample applications with Kiny running at the backend. A
demo login page was launched with kivy which simulated clicking on a login
button. the is_click option in recorderkivy.py was set to true and the screen
coordinates for the click was specified. Next the recorder was set to execute
one click per second and this was repeated for 2 hours. This workload ensured
that the critical code segments of kivy is called, a number of which also
contained smells.

Falcon. It is a WSGI library for building web APIs. The workload here mainly
includes simulating requests to a WSGI client through class
falcon.testing.TestClient(app, headers=None)[source] class which is a
contextual wrapper for simulate_*() function. This class will simulate the
entire app lifecycle in a single call, which starts from lifespan and
disconnecting process. This workload was repeated by passing the number of
repetitions to the simulate_request() function. It was repeated 300 times and
the CPU and memory usage were recorded. The same process was repeated after
refactoring the falcon source code.

Figure 1. Code smell distribution across the 31 applications analyzed in this
study.

##  3\. Results Analysis

|
---

Figure 2. Normalized plots of impact of refactoring each code smell
individually (per instance) on resource usage. X-axis: change in CPU usage
(%); Y-axis: change in memory usage (%) of the application.

In this section, we discuss the results of our experiments for both Java and
Python applications. Figure 1 shows the frequency of 16 analyzed code smell
types across all studied applications. The distribution shows that while the
number of smells differs between application no single smell is dominating.
For example, Cyclic Dependency code smell was prevalent in the highest numbers
in Java source codes as we detected 725 instances of this smell as seen in the
Figure. On the other hand, 259 instances of Orphan Variable were detected.
Given the assessment of smells distribution, we performed individual and batch
refactoring of all applications, and we recorded the CPU and memory usage
before and after the refactoring. Figure 2 shows the relative change in CPU
and memory usage we observed. Here, we define relative change as the
difference in CPU and memory usage between before and after refactoring. The
dataset for generating Figure 2 is provided
333https://github.com/asif33/batchrefactoring/tree/scatter for
reproducibility. We note that in the case of Python applications our tools
were able to detect and refactor on the following smells: dead code, cyclic
dependency, long parameter, middleman, god method, and god class. Below, we
summarize our findings for each type of smell.

dead code: We know that dead code is a code that is either redundant, because
the results are never used, or is never executed. Since the results are never
used but the code is getting executed, it is common to expect that it leads to
CPU and memory waste. In cases when the code is not executed, it can still
have adverse effect due to adding code bloat. Our results confirm that the CPU
usage can be improved by removing dead code smells. Dead code makes the
runtime footprint larger than it needs to be, thereby consuming excess
resource in terms of CPU and memory which can be critical for large scale data
center applications like OpenStack as studied in this research.

cyclic dependency: This smell can cause a domino effect on the code when a
small change in one module quickly spreads to other mutually recursive
modules. The smell caused infinite recursion in 134 instances where it was
found. In 63 instances, it resulted in memory leaks in java by preventing
garbage collectors to deallocate memory. The extent of the impact of this
smell is also dependent on the type of software as a similar type of
application is found to behave similarly. Analysis of the refactored code
shows that the refactoring process eliminates the enhanced loops in most parts
of the software, thereby improving resource usage. The enhanced loop traverses
each loop one by one, thereby requires increased CPU even when traversal of
the entire array may not be required. The refactoring tools address such cases
and removes the enhanced loops.

The removal of unwanted loops results in loop unrolling which is observed in
the refactored code of both Java and Python datasets. The loop unrolling
reduces CPU and memory consumption by removing loop overhead. At the same
time, loop control instructions and loop test instructions are eliminated, so
the resource required to conduct those activities are freed. The total number
of iterations are reduced to improve resource efficiency. As seen in the
figure, in all cases of Python and Java, removal of cyclic dependency code
smell is seen to improve resource utilization performance.

Considering $jstock$, it is seen that the refactoring of cyclic depend code
smells results in 5.89% CPU and 6.16% memory, with a standard deviation of
0.26 and 0.49 respectively. In other cases of Java dataset, improvements are
noticed as well. When we consider the dataset of Python, we see that removal
of cyclic dependency code smell decreases CPU and memory consumption for a
specific workload of tensorflowmodel by 0.33% and 0.21% respectively for each
smell refactored.

long parameter: For long parameter code smell, it is seen that out of the 24
applications, all are showing positive memory change and negative CPU change,
meaning memory usage degraded after refactoring the software smell. When we
look towards refactoring, for example in $jhotdraw$ the tool used “Introduce
Parameter Object” refactoring.

If we consider an example of a long parameter smell found in $openstack$ which
is a software of our experimental dataset of Python, we noticed that a method
with many parameters is refactored where the parameters are distributed to
three methods preserving the functionality. Although the above segregation is
a better way to provide useful and reusable classes, it is causing unboxing of
the parameters from one method to 3 methods. If one method contained all
parameters then, all those parameters could have been cached at the beginning
and it does not require loading into memory multiple times. However, this
would provide an extra load on the CPU as the parameters which were not
required at the initial stage of polygon formation would still be called.
Refactoring it in the mechanism described above will break the concatenation,
hence preventing caching. On the other hand, the prevention of caching all the
parameters at the very beginning will cause excess memory to be used. Hence,
refactoring this smell for the above 2 types of applications will reduce CPU
usage but worsen memory usage.

Although, the modularization of code improves readability, it will worsen
memory usage as more instructions need to be loaded into memory. Similar
behavior applies to the remaining 3 applications which are showing these
traits. For $openstack$ we notice that the CPU utilization reduces by 7.9%
which I significant compared to others. It must be stated that the number of
smells of the long parameter in $openstack$ was found to be 40, significantly
higher than the same smell being found in other apps. This large number of
smells may have contributed to the improvement of CPU usage.

middleman: Elimination of middle man smells contributed to the improvement of
CPU and memory usage. The most improvement is seen in $ganttproject$ with CPU
and memory usage reductions of 0.61% and 0.29% respectively. There were 58
instances of middleman code smell in the ganttproject, this resulting in a
significant performance improvement. Also, the ganttproject is a CPU-intensive
project occupying a significant percentage of CPU when running, thus yielding
greater change in CPU than memory. For Python dataset, $sentry$ had the
maximum number of middleman code smell which was detected. When the 27 code
smells in $sentry$ were refactored, per smell improvement in CPU and memory
was 0.44% and 0.13% respectively for every smell refactored.

god class: In the list of applications that were refactored it is seen that
the extract class refactoring mechanism caused the resource usage to worsen
(Alkharabsheh et al., 2021). Refactoring this smell involves a large class is
separated into multiple smaller classes, each with lesser responsibilities,
hence extra time and resources are required for inter-class communication, as
a result, CPU and memory usage increases. Further analysis shows that the
inter-class communication increased as large classes were extracted into
multiple small classes. We tool all the new methods which are created and
found the average lines of code in those. In most cases, we see that usually
16.14 lines of code trigger and complete operations on a variable or object,
based on slicing a new method needs to be made with those. From a software
engineering perspective, such large volumes of extraction are desirable,
however from the standpoint of the resource usage, such granular segregation
may cause huge volume of context switching and inter-method communications,
which may add high volume of overhead.

god method: The behavior of graph for god method is similar to that of god
class. All values are positive which shows that refactoring the god method
code smells increase resource usage. Besides, the normalized increase is quite
high for the god method compared to other kinds of code smells. To refactor
the god method, the extract method mechanism is used. So a large method is
broken down into multiple smaller methods, which increases inter-method
communication.

lazy class: The same behavior is seen for refactoring lazy class smell where
each category of applications is showing similar behavior. One exception is
that JRuby is located very close to the group of document editors. The reason
is that the number of lazy class smells of JRuby is only 9. Similar resource
consumption changes are seen for the group of editors where the number of
smells ranges from 9-13 for all the applications. Hence for $lazy$ $class$ the
number of smells is proportional to the impact on resource usage.

duplicate code: Similar behavior is seen for refactoring duplicate code smell.
It is seen that the apps belonging to the same category are behaving
similarly, emphasizing the fact that similar types of apps have the same
impact when the code smell is refactored. $Ant$, $xalan$, $maven$, and
$xerces$ are found to show significant improvement in CPU resources after
refactoring. Analysis of the code in $xerces$ shows that it parsed the XML
documents and placed the variables in those in a list, reiterating through it
multiple times.

long statement: Results of the long statement are seen to be in line with the
results of the long parameter. The CPU change after refactoring is lowered
whereas the memory usage increases. However, although the increase varies
differently for a different group of applications, the parser category shows
high usage of memory compared to the other categories.

orphan variable: Similar category of applications are seen to behave similarly
in terms of change in resource usage when the orphan variable is refactored.
As a result, it can be stated that the category of applications can be used to
group the impact of refactoring the code smell. The email clients namely $emf$
and $columba$ are seen to have the maximum impact of refactoring this code
smell.

primitive obsession: After refactoring primitive obsession code smell and
normalizing with the count of smells, it is seen that for primitive obsession
the change in resources data can be used to group the applications by
category. One of the rules which are used by the refactoring tool is to
replace $StringBuffer$ with $StringBuilder$. It is recommended to use
$StringBuilder$ because no locking and syncing is done. Hence, it’s faster.
When running programs in a single thread, which is generally the case,
$StringBuilder$ offers performance benefits over $StringBuffer$.

refused bequest: We see that the impact of automated refactoring is higher for
the group of code analyzer apps than the others. This is because the testing
apps loaded the source code in memory to run the tests. The presence of unused
methods and variables in the code which is loaded into memory resulted in
excessive resource usage by the applications. On average, after refactoring
0.284% of CPU and 0.147% of memory were reduced for each refused bequest smell
refactored.

shotgun surgery: For log4j, it is seen that refactoring the shotgun surgery
significantly contributed to improving memory resources by 7%. Refactoring
this code smell also improved the unpredictability and efficiency of the
generated random values. Simplification of the data structures occurred in 21
of the cases of refactoring, a high percentage of 61.76% where this
refactoring was done, thus simplifying the code significantly. As most of the
loops were used to read and load the logs in memory, simplifying it meant that
less memory will be required for loading.

spaghetti code: The $jruby$ application had the highest impact of refactoring
the spaghetti code smell. The number of spaghetti codes detected in this
application is 57, which is higher than any application in the list. This
resulted in more loc being refactored and greater change in resource usage
before and after refactoring. One of the rules of refactoring spaghetti code
replaced the $concat()$ method on Strings with the + operator. It should have
slight performance benefits if the size of the $concat()$ is large. Another
rules replaced $length()$ or $size()$ with $isEmpty()$. This rule should
provide performance advantages since $isEmpty()$ time complexity is $O(1)$
whereas $length()$ and $size()$ can have a time complexity of $O(n)$.

speculative generality: It is seen that the code parser category showed the
highest change in CPU and memory utilization for speculative generality. This
category of applications has 76 cases of speculative generality and non-
normalized CPU usage improved by 4.63% and memory improved by 1.47% due to
refactoring of the smells. This increase is mainly due to the removal of
excess code that was added but not called in the system. These codes kept
using heap memory and used CPU for basic non-required computations.

temporary variable: Given the lower number of smells detected for this smell
type in the applications, the grouping of applications in the plots based on
category implies that the smell is having an impact on the resource change.
Also, the refactoring does not keep temporary fields, thus making those final,
leading to improvement in resource consumption.

###  3.1. Impact of Batch Refactoring

In the previous section, we did a benchmark by analyzing the impact of
individually refactoring the smells on resource usage. Although it helped us
determine a benchmark, however, in real life no software occurs with a single
type of smell only. Hence it is very important to see the combined impact of
smell refactoring on resource usage. Also, we want to see whether the combined
impact adds up to the individual impact of refactoring different smell types
since this will ensure that the change in resource usage is caused by the code
smell refactoring. With this requirement in mind, we proceed to refactor the
smells in batch as shown in Figure 3, 4, and 5. The dataset of the Figures can
be viewed from the link
444https://github.com/asif33/batchrefactoring/tree/batch-refactor.

####  3.1.1. Refactoring all code smells.

Here we refactored and analyzed the impact of the 16 smells altogether. In
this section, we provide the findings in terms of CPU and memory usage. We
analyze the impact on CPU and memory separately. Figure 3 shows the impact of
refactoring those smells.

Impact on CPU: Combined refactoring of all the smells, irrespective of impact
can provide useful information as to whether those smells improve resource
usage or worsen those. It is seen that although the individual impacts of
performance degrading smells is significant, refactoring all the 16 smells in
24 applications resulted in improvement of the resource usage overall since
the type of resource usage improving smells were larger compared to those
which worsen performance. From the CPU perspective, it is seen that the total
CPU usage of ant improved by 30.01% which is significant and desirable. At the
same time, the least percentage improvement was seen in $Javacc$ which is
8.10%. It is seen that the percentage improvement of CPU is greatly influenced
by the presence of the numbers of various types of smells.

Impact on memory: A similar pattern is seen for memory consumption where the
usage improves after refactoring the 16 smells studied in this research where
$ant$ showed the highest improvement of 39.70%. The lowest change in CPU usage
was seen for $jparse$ with a 3.50% improvement. Again the increase can be
credited to the total instances of the various types of smells found in the
un-refactored code.

####  3.1.2. Refactoring code smells that increase resource usage.

Impact on CPU: It is seen that refactoring god class, god method, and feature
envy negatively impact performance when refactored. Upon analysis of the
normalized graph for god class and god method, it is seen that per smell
impact of god class is found to be around 0.22%-0.50%, whereas for god class
it is 0.20%-0.22%, indicating that a software engineer who is focusing on
refactoring and has optimizing resource usage in mind should avoid refactoring
god classes and god methods.

At the same time, it is seen that $ganttproject$ suffers from the largest
percentage increase of CPU usage which is undesirable. In total $ganttproject$
had 61 occurrences of smells of god class and god method, refactoring which
greatly impacted to resource usage degradation of 16.30%. On average the total
degradation of CPU usage after refactoring the smells for 24 applications is
found to be 7.79%. Upon refactoring the individual smells and adding the total
change in CPU usage, we get similar values to refactoring them altogether.

Impact on memory: Refactoring god class and god method worsened memory usage
as well for the 24 applications. Log4j had the highest degradation of memory
consumption which is 19.50% when the concerned smells were refactored
altogether. Also, refactoring those individually and adding up the values
resulted in total memory consumption of 20.01%, which is only 0.51% greater
than combined refactoring, ensuring that the results are adding up to
individual impact and hence they are consistent. The large number of smells of
god classes and god methods which sum up to 100 instances of smells being
present in the code leads to a large volume of refactoring done in the code by
the implementation of extract class and extract method refactoring procedures.
This contributed to the large distortion of memory usage before and after
refactoring. Overall, we see that individual refactoring impacts add up when
the refactoring is done combined procedure. The mean deviation in CPU is 0.64%
and the mean deviation in memory is 1.47%.

####  3.1.3. Refactoring code smells that decrease resource usage.

This section states the impact of auto-refactoring all the smells at once
which positively impacts resource usage. Similar to the last section, we
highlight the impact on CPU and memory separately and analyze the consistency
as shown in Figure 4.

Impact on CPU: We analyzed refactoring which smells consistently improved
performance for our dataset of 24 apps in this study and found that cyclic
dependency, duplicate code, dead code, primitive obsession, speculative
generality, shotgun surgery, long parameter, middle man, refused bequest,
orphan variables, long statements, and temporary fields were seen to meet our
condition. We proceeded to refactor the aforementioned smells altogether and
determine the total change in CPU and memory when they are refactored
combinedly. Out of the 24 applications, $columba$, $log4j$, and $jruby$ gave
errors when the smells which improved performance individually were refactored
together. As shown in Figure 2 for CPU, it is seen that the range of
percentage improvement of CPU stretched from 7.6% for $jparse$ till 37.70% for
$ant$. We proceeded to sum the impact of refactoring those smells individually
for comparison purposes. It is seen that combining impact stretched from 7.86%
to 38.87%. Upon calculation of the differences, it is seen that combining all
the smells whose refactoring improves performance show consistent behavior to
refactoring them individually and adding the values. The difference in the
values ranged from 0.26% to 1.46% which were seen for $jparse$ and $emf$
respectively. The mean deviation is 0.61%.

Impact on memory: The memory usage is impacted significantly with a range of
25.47% and 47.77% for the apps and an average improvement of 28.63%. It is
seen that $jmeter$ shows the maximum improvement whereas $emf$ shows the
minimal effect on memory. Further analysis shows that when the smells are
refactored in $jmeter$, the volume of spatial locality is increased due to the
rearrangement done to it. Also, compression is conducted by dissolving longer
parameters which result in smaller and smarter formats. Finally, temporal
localities are increased by refactoring smells like a refused bequest, shotgun
surgery, and speculative generality which cache trashing, hence reducing
memory usage. Reduce and reuse refer to techniques that minimize memory
operations with the temporal locality that reduce cache fetches. This is
accomplished by reuse of data still in the cache by merging loops that use the
same data with a mean deviation of 0.64%.

Based on the findings of this section, we use the experimental data to deploy
train and test machine learning techniques to predict the impact of the smells
based on the detection and before they are refactored.

---
(a) impact on CPU

---
(b) impact on memory

Figure 3. Combined refactoring impact of all smells considered in this
research.

---
(a) impact on CPU

---
(b) impact on memory

Figure 4. Combined impact of smell refactoring which improve resource usage.

---
(a) impact on CPU

---
(b) impact on memory

Figure 5. Combined impact of smell refactoring which worsen resource usage. Smell | Mean difference
---|---
cyclic dependency | 0.070
dead code | 0.095
middleman | 0.045
long parameter | 0.055
god class | 0.060
god method | 0.095
Table 2. Generalized impact of code smell refactoring

###  3.2. Predicting Resource Utilization Impact

| Linear regression | Polynomial regression | Lasso regression | Random forest | ANN-regression
---|---|---|---|---|---
code smell | mse | rmse | mse | rmse | mse | rmse | mse | rmse | mse | rmse
cyclic dependency | 1.50 | 1.78 | 1.41 | 1.66 | 0.73 | 0.89 | 0.53 | 0.71 | 0.43 | 0.62
god class | 1.85 | 2.01 | 0.63 | 1.03 | 0.66 | 0.89 | 0.47 | 0.66 | 0.31 | 0.37
god method | 0.84 | 0.96 | 0.76 | 0.81 | 0.62 | 0.70 | 0.47 | 0.56 | 0.25 | 0.43
dead code | 1.42 | 1.59 | 0.32 | 0.51 | 0.32 | 0.50 | 0.29 | 0.46 | 0.22 | 0.32
long parameter | 1.52 | 1.61 | 0.41 | 0.51 | 0.33 | 0.49 | 0.21 | 0.36 | 0.19 | 0.22
middleman | 1.67 | 1.98 | 0.81 | 1.12 | 0.71 | 0.98 | 0.44 | 0.86 | 0.21 | 0.28
Table 3. Results of multivariate regression analysis for memory.

In this section, we proposed an approach based on machine learning (ML) using
different metrics of the software and the number of code smells detected to
predict the resource consumption changes due to code smell refactoring. We
find that the selection of relevant software metrics as features plays an
important role in the performance of the ML algorithms. Our dataset was
created using the benchmarking procedure discussed earlier in this paper. We
used a genetic algorithm for feature selection and find that for all the
algorithms, the performance is best is improved for a certain combination of
relevant features.

Our experiments included four machine learning algorithms namely linear
regression, polynomial regression, lasso regression, random forest regression,
and ANN-regression. The ANN-regression model achieved the best performance as
shown in Table 3. The table shows the regression results for the 6 code smells
which were detected in both Java and Python applications. The rest of the
results can be found
555https://github.com/asif33/batchrefactoring/blob/applications/regression-
data-remaining-smells.png.We see that the regression algorithms have a high
potential for predicting resource consumption impact by refactoring code
smells.

Despite determining the CPU impact for individual and batch refactoring of
code smells, software engineers want to identify this impact even before they
conduct refactoring. This will enable them to decide which software code
smells to address during the refactoring phase to save time and engineering
effort. Here, we used the data of bench-marking to predict resource usage
change via regression analysis. In this regard, we identified some features of
the code smells such as lines of code with smells, weighted method per class,
FanIn, FanOut, and category of applications, number of smells which impact
resource usage. We applied a $Naive$ approach which involved taking the mean
of normalized CPU and memory of all applications except for the target
application. Next, we used the mean to predict the resource usage of the
target app by considering the identified features. We proceeded to calculate
the Mean Squared Error (MSE) for both the CPU and memory. The MSE for CPU was
found to be $0.02216$ and for memory, it was $0.03165$.

After the $Naive$ approach, we applied linear regression to predict the CPU
and memory usage. We used features of the code smells to predict the impact on
resource usage. The first part of the exercise considered the impact
prediction of individual features. Next, we conducted multivariate regression
analysis which provided the impact of each independent variable on the
dependent variables. We see that the $MSE$ is minimum when we combined all
independent variables in the multivariate approach. This result is desirable
and low $MSE$ indicates that we can predict the change resource usage for
refactoring code smells in apps even before we do the refactoring. The $MSE$
for multivariate regression for CPU was $0.01161$ and for memory, it was
$0.02011$.

The estimate is the average impact per refactored smell on CPU and memory by a
specific feature when all other features remained constant. This is used as a
coefficient in the regression formula. The ratio of the estimate and standard
error provided us the $t-value$. Positive $t-values$ were observed for all 16
smells. Adjusted r-squared was found to be $0.891$ and $0.833$ for CPU and
memory respectively, indicating that the model can explain 89.1% of the
variations in the training data set. Although regression analysis gives us
promising results, there is a need to conduct a detailed future study in
prediction of code smells impact on resource usage.

##  4\. Related Work

Automated batch refactoring techniques are known to significantly improve
overall software quality and maintainability, but their impact on resource
utilization is not well studied in the literature. Oliveira et al. conducted
an empirical study to evaluate nine context-aware Android apps to analyze the
impact of automated refactoring of code smells on resource consumption
(Oliveira et al., 2018) of Android applications. They studied three code
smells, namely god class, god method, and feature envy. They found that for
the three smells, resource utilization increases when they are refactored.
Although their findings are useful, it is limited to the analysis of three
code smells only. At the same time, the importance of analyzing the impact of
batch refactoring code smells on software resource usage was not considered.

To understand the relationship between Android code smells and nonfunctional
factors like energy consumption and performance, Palomba et al. (Palomba et
al., 2019) conducted a study with nine Android-specific smells and 60 Android
applications. Their results showed that some smell types cause much higher
energy consumption compared to others and refactoring those smells improved
energy consumption in all cases. Although the results are consistent with our
findings, the authors only addressed the individual impact of nine code smells
and the analyzed smells were specific to Android applications.

The impact of multiple refactoring on code maintainability, also known as
batch refactoring, was explored by Bibiano et al. (Bibiano et al., 2019). They
argue that removing an individual code smell in a code block increases the
tendency of introducing new smells by 60%. Therefore, the importance of
analyzing the combined and complex impact of refactoring code smells in a
batch rather than individual smells is proposed. Besides maintainability, it
is also essential to study the effect of batch refactoring on the resource
usage of the application.

Park et al. investigated whether existing refactoring techniques support
energy-efficient software creation or not (Park et al., 2014). Since low-power
software is critical in mobile environments, they focused their study on
mobile applications. Results show that specific refactoring techniques like
the Extract Class and Extract Method can worsen energy consumption because
they did not consider power consumption in their refactoring process. The goal
was to analyze the energy efficiency of the refactoring techniques themselves,
and they stated the need for energy-efficient refactoring mechanisms for code
smells.

Platform-specific code smells in High-Performance Computing (HPC) applications
were determined by Wang et al. (Wang et al., 2014). AST-based matching was
used to determine smells present in HPC software. The authors claimed that the
removal of such smells would increase the speedup of the software. The
assumption was that specific code blocks perform well in terms of speedup in a
given platform. However, the results show that certain smell detection and
refactoring reduced the speedup, thus challenging the claims and showing the
importance of further research in this area.

Pérez-Castillo et al. stated that excessive message traffic derived from
refactoring god class increases a system’s power consumption (Pérez-Castillo
and Piattini, 2014). It was observed that power consumption increased by 1.91%
(message traffic = 5.26%) and 1.64% (message traffic = 22.27%), respectively,
for the two applications they analyzed. The heavy message-passing traffic
increased the processor usage, which proved to be in line with the increase in
the power consumption during the execution of those two applications. The
study was limited to only god class code smell. However, a detailed analysis
is required to determine the impact of code smell refactoring on resource
consumption.

An automatic refactoring tool that applied the Extract Class module to divide
a god class into smaller cohesive classes was proposed in (Fokaefs et al.,
2011). The tool aimed to improve code design by ensuring no classes are large
enough, which is challenging to maintain and contains a lot of
responsibilities. The tool refactored code by suggesting Extract Class
modifications to the users through a User Interface. The tool was incorporated
into the Eclipse IDE via a plugin. The authors consulted an expert in the
software quality assessment field to give his expert opinion to identify the
effectiveness of the tool. Results show that in 12 cases (75%), the evaluator
confirmed that the classes suggested being extracted indeed described a
separate concept. According to the expert, two of these classes could be
extracted and used as utility or helper classes. However, the effect of such
refactoring on resource usage of the software was considered to a limited
extent.

The results showed that refactoring smells by automated tools like JDeodorant
and JSparrow have widely varying impacts on the CPU and memory consumption of
the tested applications based on the specific smell types. We presented each
smell’s resource utilization impact and discussed the potential reasons
leading to those effects.

##  5\. Conclusion

In this paper, we evaluated the impact of batch refactoring 16 code smells on
the resource usage of 31 open-source Java and Python applications. We provided
a detailed empirical analysis of the change in the CPU and memory utilization
after auto-refactoring specific code smells in isolation as well as in
combination with other smells. Obtained results highlight that the refactoring
techniques adopted for code smells such as god class and god method adversely
affected CPU and memory usage of the application. Refactoring Long Parameters
smell resulted in improvement of CPU usage but worsened memory usage.
Refactoring all other code smells improved resource usage for the same
workload. We noticed that applications belonging to the same category were
impacted similarly by refactoring specific smells. Also, the impacts of smells
on resource consumption for Java and Python applications were quite similar;
hence our results can be generalized. Combined refactoring of various code
smells add up to the impact of refactoring those smells individually. Based on
these observations, we suggested a set of guiding principles on selecting the
correct set of code smells to be refactored for the most efficient resource
utilization. We also provided a mechanism based on regression analysis to
accurately predict the impact of batch refactoring code smells on CPU and
memory utilization before making refactoring decisions.

## References

  * (1)
  * Aarniala (2005) Jari Aarniala. 2005\.  Instrumenting java bytecode. In _Seminar work for the Compilerscourse, Department of Computer Science, University of Helsinki, Finland_.
  * Abbes et al. (2011) Marwen Abbes, Foutse Khomh, Yann-Gael Gueheneuc, and Giuliano Antoniol. 2011.  An empirical study of the impact of two antipatterns, blob and spaghetti code, on program comprehension. In _2011 15th European Conference on Software Maintenance and Reengineering_. IEEE, 181–190.
  * Alkharabsheh et al. (2021) Khalid Alkharabsheh, Yania Crespo, Manuel Fernández-Delgado, José R Viqueira, and José A Taboada. 2021.  Exploratory study of the impact of project domain and size category on the detection of the God class design smell.  _Software Quality Journal_ (2021), 1–41.
  * Anvik et al. (2005) John Anvik, Lyndon Hiew, and Gail C Murphy. 2005.  Coping with an open bug repository. In _Proceedings of the 2005 OOPSLA workshop on Eclipse technology eXchange_. 35–39.
  * Anwar et al. (2019) Hina Anwar, Dietmar Pfahl, and Satish N Srirama. 2019\.  Evaluating the impact of code smell refactoring on the energy consumption of Android applications. In _2019 45th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)_. IEEE, 82–86.
  * Armbrust et al. (2009a) Michael Armbrust, Armando Fox, Rean Griffith, A Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, et al. 2009a.  A Berkeley view of cloud computing.  _UC Berkeley EECS Technical Report EECS-2009-28_ (2009).
  * Armbrust et al. (2009b) Michael Armbrust, Armando Fox, Rean Griffith, Anthony D Joseph, Randy H Katz, Andrew Konwinski, Gunho Lee, David A Patterson, Ariel Rabkin, Ion Stoica, et al. 2009b.  _Above the clouds: A berkeley view of cloud computing_.  Technical Report. Technical Report UCB/EECS-2009-28, EECS Department, University of California, Berkeley.
  * Ayewah et al. (2007) Nathaniel Ayewah, William Pugh, J David Morgenthaler, John Penix, and YuQian Zhou. 2007.  Using findbugs on production software. In _Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion_. 805–806.
  * Bibiano et al. (2019) Ana Carla Bibiano, Eduardo Fernandes, Daniel Oliveira, Alessandro Garcia, Marcos Kalinowski, Baldoino Fonseca, Roberto Oliveira, Anderson Oliveira, and Diego Cedrim. 2019\.  A Quantitative Study on Characteristics and Effect of Batch Refactoring on Code Smells. In _2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)_. 1–11.  https://doi.org/10.1109/ESEM.2019.8870183
  * Ćirić and Rančić (2005) Miroslav D Ćirić and Svetozar R Rančić. 2005\.  Parsing in different languages.  _Facta universitatis-series: Electronics and Energetics_ 18, 2 (2005), 299–307.
  * Cromar (2013) Scott Cromar. 2013\.  GanttProject.  In _From Techie to Boss_. Springer, 225–229.
  * Dietz and Stitch (2017) Frederick. Dietz and Timo Stitch. 2017.  Columba Email Client Project.  _URL: http://columba.sourceforge.net/testing/index.php(visited on 2/11/2021)_ (2017).
  * Dos Reis (2012) Anthony J Dos Reis. 2012\.  _Compiler Construction Using Java, JavaCC, and Yacc_.  John Wiley & Sons.
  * Duong et al. (2017) Long Duong, Hadi Afshar, Dominique Estival, Glen Pink, Philip R Cohen, and Mark Johnson. 2017\.  Multilingual semantic parsing and code-switching. In _Proceedings of the 21st Conference on Computational Natural Language Learning (CoNLL 2017)_. 379–389.
  * Fernandes (2019) Eduardo Fernandes. 2019\.  Stuck in the middle: Removing obstacles to new program features through batch refactoring. In _2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)_. IEEE, 206–209.
  * Fokaefs et al. (2011) Marios Fokaefs, Nikolaos Tsantalis, Eleni Stroulia, and Alexander Chatzigeorgiou. 2011.  JDeodorant: identification and application of extract class refactorings. In _2011 33rd International Conference on Software Engineering (ICSE)_. IEEE, 1037–1039.
  * Fowler (2018) Martin Fowler. 2018\.  _Refactoring: improving the design of existing code_.  Addison-Wesley Professional.
  * Gamma (1995) Erich Gamma. 1995\.  _Design patterns: elements of reusable object-oriented software_.  Pearson Education India.
  * Gulabovska and Porkoláb (2019) Hristina Gulabovska and Zoltán Porkoláb. 2019.  Survey on Static Analysis Tools of Python Programs.. In _SQAMIA_.
  * Halili (2008) Emily H Halili. 2008\.  _Apache JMeter_.  Packt Publishing Birmingham.
  * Holzer et al. (2009) Andreas Holzer, Visar Januzaj, and Stefan Kugele. 2009\.  Towards resource consumption-aware programming. In _2009 Fourth International Conference on Software Engineering Advances_. IEEE, 490–493.
  * IT-Consulting (2020) Splendid IT-Consulting. 2020\.  _JSparrow_.
  * Jacob et al. (2010) Ferosh Jacob, Daqing Hou, and Patricia Jablonski. 2010.  Actively comparing clones inside the code editor. In _Proceedings of the 4th International Workshop on Software Clones_. 9–16.
  * James ([n.d.]) J James. [n.d.].  JParse: A Java Parser.  _Retrieved (11 September 2004) from http://www. ittc. ku. edu/JParse_ ([n. d.]).
  * Leung (2004) Theodore W Leung. 2004\.  _Professional XML Development with Apache Tools: Xerces, Xalan, FOP, Cocoon, Axis, Xindice_.  John Wiley & Sons.
  * Liu et al. (2014b) Wen Zhi Liu, Qiu Yan Tao, Qin He, and Li Juan Yu. 2014b.  Application of Log4j in E-Commerce Services. In _Applied Mechanics and Materials_ , Vol. 635. Trans Tech Publ, 1517–1521.
  * Liu et al. (2014a) Yan Yun Liu, Bin Hu, Li Ping Rao, and Lin Pan. 2014a.  Java Code Coverage Test Technology Based on EMMA. In _Advanced Materials Research_ , Vol. 1049. Trans Tech Publ, 2069–2072.
  * Murphy-Hill (2008) Emerson Murphy-Hill. 2008\.  Scalable, expressive, and context-sensitive code smell display. In _Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications_. 771–772.
  * Myers (1978) Glenford J Myers. 1978\.  A controlled experiment in program testing and code walkthroughs/inspections.  _Commun. ACM_ 21, 9 (1978), 760–768.
  * Nutter et al. (2014) Charles Nutter, Thomas Enebo, Ola Bini, Nick Sieger, et al. 2014\.  JRuby.  _URL: http://jruby. org/(visited on 12/11/2013)_ (2014).
  * Oliveira et al. (2018) Johnatan Oliveira, Markos Viggiato, Mateus F Santos, Eduardo Figueiredo, and Humberto Marques-Neto. 2018\.  An Empirical Study on the Impact of Android Code Smells on Resource Usage.. In _SEKE_. 314–313.
  * O’Hair (2004) Kelly O’Hair. 2004\.  HPROF: a Heap/CPU profiling tool in J2SE 5.0.  _Sun Developer Network, Developer Technical Articles & Tips_ 28 (2004).
  * Paixão et al. (2020) Matheus Paixão, Anderson Uchôa, Ana Carla Bibiano, Daniel Oliveira, Alessandro Garcia, Jens Krinke, and Emilio Arvonio. 2020\.  Behind the intents: An in-depth empirical study on software refactoring in modern code review. In _Proceedings of the 17th International Conference on Mining Software Repositories_. 125–136.
  * Palomba et al. (2019) Fabio Palomba, Dario Di Nucci, Annibale Panichella, Andy Zaidman, and Andrea De Lucia. 2019\.  On the impact of code smells on the energy consumption of mobile applications.  _Information and Software Technology_ 105 (2019), 43–55.
  * Park et al. (2014) Jae Jin Park, Jang-Eui Hong, and Sang-Ho Lee. 2014.  Investigation for Software Power Consumption of Code Refactoring Techniques.. In _SEKE_. 717–722.
  * Parr and Quong (1995) Terence J. Parr and Russell W. Quong. 1995.  ANTLR: A predicated-LL (k) parser generator.  _Software: Practice and Experience_ 25, 7 (1995), 789–810.
  * Pérez-Castillo and Piattini (2014) Ricardo Pérez-Castillo and Mario Piattini. 2014.  Analyzing the harmful effect of god class refactoring on power consumption.  _IEEE software_ 31, 3 (2014), 48–54.
  * Riungu-Kalliosaari et al. (2011) Leah Riungu-Kalliosaari, Ossi Taipale, and Kari Smolander. 2011\.  Testing in the cloud: Exploring the practice.  _IEEE software_ 29, 2 (2011), 46–51.
  * Rutar et al. (2004) Nick Rutar, Christian B Almazan, and Jeffrey S Foster. 2004\.  A comparison of bug finding tools for java. In _15th International symposium on software reliability engineering_. IEEE, 245–256.
  * Samarthyam et al. (2016) Ganesh Samarthyam, Girish Suryanarayana, and Tushar Sharma. 2016\.  Refactoring for software architecture smells. In _Proceedings of the 1st International Workshop on Software Refactoring_. 1–4.
  * Santos et al. (2020) Rafael Meneses Santos, Methanias Colaço Rodrigues Junior, and Manoel Gomes de Mendonça Neto. 2020\.  Self-Admitted Technical Debt classification using LSTM neural network. In _17th International Conference on Information Technology–New Generations (ITNG 2020)_. Springer, 679–685.
  * Sarkar et al. (2012) Santonu Sarkar, Girish Maskeri Rama, Nagaraja Nanjegowda Siddaramappa, Avinash C Kak, and Shubha Ramachandran. 2012.  Measuring quality of software modularization.  US Patent 8,146,058.
  * Savolskyte (2004) Jolita Savolskyte. 2004\.  Review of the JHotDraw framework.  _Harlow, Information and Media Technologies_ (2004).
  * Sefraoui et al. (2012) Omar Sefraoui, Mohammed Aissaoui, and Mohsine Eleuldj. 2012\.  OpenStack: toward an open-source solution for cloud computing.  _International Journal of Computer Applications_ 55, 3 (2012), 38–42.
  * Shvets ([n.d.]) Alexander Shvets. [n.d.].  Java Code Smells, https://refactoring.guru/, 2021.
  * Tempero et al. (2010) Ewan Tempero, Craig Anslow, Jens Dietrich, Ted Han, Jing Li, Markus Lumpe, Hayden Melton, and James Noble. 2010\.  Qualitas Corpus: A Curated Collection of Java Code for Empirical Studies. In _2010 Asia Pacific Software Engineering Conference (APSEC2010)_. 336–345.  https://doi.org/10.1109/APSEC.2010.46
  * Vakilian et al. (2012) Mohsen Vakilian, Nicholas Chen, Stas Negara, Balaji Ambresh Rajkumar, Brian P Bailey, and Ralph E Johnson. 2012.  Use, disuse, and misuse of automated refactorings. In _2012 34th International Conference on Software Engineering (ICSE)_. IEEE, 233–243.
  * Verdecchia et al. (2018) Roberto Verdecchia, René Aparicio Saez, Giuseppe Procaccianti, and Patricia Lago. 2018\.  Empirical Evaluation of the Energy Impact of Refactoring Code Smells.. In _ICT4S_. 365–383.
  * Wang et al. (2014) Chunyan Wang, Shoichi Hirasawa, Hiroyuki Takizawa, and Hiroaki Kobayashi. 2014.  A platform-specific code smell alert system for high performance computing applications. In _2014 IEEE International Parallel & Distributed Processing Symposium Workshops_. IEEE, 652–661.
  * Wenzel (2012) Makarius Wenzel. 2012\.  Isabelle/jEdit–a Prover IDE within the PIDE framework. In _International Conference on Intelligent Computer Mathematics_. Springer, 468–471.
  * Zimmermann et al. (2007) Thomas Zimmermann, Rahul Premraj, and Andreas Zeller. 2007\.  Predicting defects for eclipse. In _Third International Workshop on Predictor Models in Software Engineering (PROMISE’07: ICSE Workshops 2007)_. IEEE, 9–9.