AN EMPIRICAL STUDY ON DETECTION AND REMOVAL OF BAD SMELLS INSTANTLY

USING A INSREFACTOR

M.INDUMATHI
Department of Computer Science,
Bangalore
indumscmphil@gmail.com

ABSTRACT:
Refactoring reduces the cost of software maintenance through changing the internal structure of the
source-code to improve the overall design that helps the present and future developers to evolve and
understand a system. It describes new refactoring methods and metrics along with the existing metrics to
identify the characteristics of bad smells “Lazy Class” and “Temporary Field” through which the
developer can be provided with significant guidance to locate bad smells. After identifying these bad
smells, appropriate refactoring methods can remove them.
Refactoring is a technique to make a computer program more readable and maintainable and also
used to improve the software quality without affecting any of the external functionality of the software. A
bad smell is an indication of some setback in the code, which requires refactoring to deal with. Many
tools are available for detection and removal of this code smells. They were numerous of software
refactoring tools and code smells detection tools which are to be automatic or semi automatic. Most of
these tools were human driven, so Software refactoring depends on developers’ spontaneity. Due to little
experience in software refactoring this may cause poor software quality and delays in refactoring. For
this, we have proposed a framework called Instant Refactoring by Monitor framework using Ins Refactor
which helps the inexperienced software engineers to do more refactoring quickly. Source code are
instantaneously analyzed by the Monitor, if changes occur and it to be a code smells (symbols of possible
problem in the code which requires refactoring) then framework invokes smells detection tools which
helps the programmer to resolve the bad smells instantly without delay in time. The proposed framework
has been evaluated, implemented and compared with the human-driven refactoring tools.

INTRODUCTION
Software Refactoring is to reframe the code in a series of small interior structure of objected oriented
software that to improve the software quality based on the terms of maintainability, extensibility and
reusability without changing the external behavior of the software. The term Refactoring was first
proposed by Opdyke, after it became popular by the book written by Fowler et.al that published in the
year 1999. Refactoring was tracked by the re-structuring which was the extended history in the literature.
Kim et.al assessed the value of software refactoring within Microsoft and suggested that refactoring is
visible. Software refactoring tools are significant to support. For this, researchers have proposed tools to
provide software refactoring. Most predictable Integrated Development Environment (IDE) such as
Eclipse, Microsoft Visual Studio and IntelliJ IDEA provide tool support to conduct refactoring.
Developers have to identify the refactoring opportunities’ if not they can’t apply refactoring tools.
Researchers have précised a number of typical situations which may need refactoring which Fowler calls
bad smells. Experts proposed various Smells detection algorithms that to identify different kinds of code
smells that may be automatic or semi-automatic.
Extant refactoring tools and smells detection tools are inactive and human driven. Murphy Hill et.al,
programmers fail to invoke refactoring tools and smells detection tools which may result in delay of
refactoring and results in higher cost of refactoring. The reason for this is that unaware of extant tools,
don’t know where to invoke the tools and when to detect and resolve code smells.
This paper is to make the essential to take inexperienced software engineers to carry out more software
refactoring quickly. Next we proposed an Monitor based clamant refactoring framework. Finally, we
apply and evaluate the proposed framework and the result might help inexperienced software engineers in
remove more code smells quickly.
Refactoring has become a well known technique for the software engineering community. Martin
owler has defined it as a process to improve the internal structure of a program without altering its
external behavior. Frequent refactoring of the code helps programmer to make the code more
understandable, find bugs and make it suitable for the addition of new features and to program faster.
Above all that, it improves the design of the software and therefore the overall quality of the software.
Refactoring can be done manually as well as automatically. Extensive literature is available on refactoring
of the object oriented-programs and a number of tools are available for the automatic refactoring of the
code. Refactoring has a special relationship with the concepts of reverse engineering and agile software
development. One of agile software development models, eXtreme Programming (XP), proposed by beck,
considers refactoring as one of its essential features. Refactoring continuously improves the design of the
software and helps the evolution and incremental development of the software. Different steps for the
activity of refactoring have been proposed by different researchers. Tom Mens et al., described six
activities in the process of refactoring. These are: Identifying; where refactoring should be done,
determining which refactoring(s) should be applied to the identified places, ensuring that the applied
refactoring preserves behavior, applying the refactoring, assessing the effects of refactoring on the quality
of the software and process, assessing the consistency between the code and other software artifacts.
PROBLEM DESCRIPTION
A software system becomes harder to maintain as it evolves over a period of time. Its design
becomes more complicated and difficult to understand; hence it is necessary to reorganize the code once
in a while. The most important thing when reorganizing code is to make sure that the program behaves
the same way as it did before the reorganization has taken place. Semantic preserving program
transformations are known as refactoring. The idea of refactoring is first introduced by William Opdyke
in 1992. The behavior preservation criterion is also discussed in his work.
In the past, refactoring were not taken into the mainstream development process because applying
refactoring by hand is error-prone and time consuming. The benefits of refactoring are not obvious to
many developers because refactoring neither adds new features to the software nor improves any external
software qualities.
Therefore, many system developers give refactoring low priority. They are afraid that doing so
would slow down the process and/or break their working code. Though refactoring does not help improve
external software qualities, it helps improve internal software qualities such as reusability, maintainability
and readability. It is inarguable that software design changes frequently during the development.
Performing refactoring introduces a good coding discipline as it encourages reuse of existing code rather
than rewriting new code from scratch.
Refactoring is usually initiated/invoked by the developer. Most software developers only refactor
their code when it is really necessary because this process requires in-depth knowledge of the software
system. While many experienced developers can recognize the pattern and know when to refactor, novice
programmers may find this process very difficult. Even with the knowledge of refactoring, it is not easy
for the developer to determine which part of their code can benefit from refactoring. Many programmers
learn from their experience. New generation programmers are more fortunate since Martin Fowler and
Kent Beck address this issue in their book on Refactoring. They provide a list of troubled code patterns
which could be alleviated by refactoring. Such patterns are widely known as code smells or bad smells.
Recent work by Mantyla and others attempts to make Fowler's long monotonous list of smells more
understandable. In their work, smells are classified into 7 different categories.
The taxonomy helps recognize relationships between smells and make them more comprehensible to the
developer. Despite the presence of such guidelines, finding code smells is not trivial. First and foremost,
the developer has to recognize those patterns. The problem is, even if he can recognize them, he may not
realize it when he finds one. Such a task becomes much more difficult for a large scale software system.
 The process of detecting and removing code smells with refactoring can be overwhelming.
Without experience and knowledge of the design of the particular software, the risks of breaking the code
and making the design worse are high. Applying refactoring carelessly can inadvertently change program
behavior. When refactoring is carefully applied, we not only preserve the program behavior but also avoid
introducing new bugs.
Many refactoring tools have been developed. There are also a number of works on finding
refactoring candidates .Nonetheless, these two frameworks usually work separately. It is unfortunate to
see two related frameworks work on their own and not utilize the benefits to their maximum potentials.
The relationship between code smells and refactoring are obvious but not many people have put them
together.
PROPOSED SOLUTION
Code smells detection and refactoring are connected. While code smells represent design aws in
the software, refactoring is the process which restructures and transforms the software. In other words,
code smells tell what the problems are and refactoring can then be used to correct such problems.
Integrating these two processes would provide the complete process of locating the design aws and
improving software design. The integrated framework also provides other benefits which include:
1. Clearer Connection between Smells and Refactoring: It is evident that code smells and
refactoring are related. However, the connections are abstract and usually obscured by their complexities.
Putting them in the same framework presents their relationships in a more concrete way.
2. Analysis Information Reuse: Checking conditions before refactoring and detecting code smells
require similar analyses. It is unnecessary to perform an analysis for information that we already have.
Reusing analysis information makes the framework more efficient.
However, to be able to correctly reuse the information, we have to keep track the parts of the program that
change. Then, we must determine which analysis needs to be rerun to address those changes. The
overhead of this framework will be keeping tracks of changes made on the code. I believe that such
overhead is a small sacrifice for improved efficiency.
3. Continuous Programming Flow: With the combined framework, the developer can check for
code smells and remove them without disrupting the owner of their coding. It encourages the developer to
make changes incrementally.
Some code smells introduce design change and require the developer's assistance. Not all code
smells can be automatically detected. Hence, this work focuses only on those that can be detected
automatically.

REVIEW OF LITERATURE
 According to Opdyke each refactoring basically consists of preconditions, mechanics and post
conditions. All preconditions must be satisfied before applying refactoring. Likewise, all post conditions
must be met after refactoring is applied1. These conditions ensure that the program behavior is preserved.
Opdyke also categorizes refactoring into low-level and high-level refactoring. Low-level refactoring are
related to changing a program entity (e.g., create, move, delete). High-level refactoring are usually
sequences of low-level refactoring. He also provides proofs of behavior preservation for many
refactoring.
The behavior preservation proofs of some low-level refactoring are trivial but implementing them
is not as trivial .The use of term \post condition" in this research is different from the standard use of post
conditions. Here we have post conditions apply to perform checks that are difficult to do before the
transformation takes place.
Refactoring Tools
In early 1990s, Don Roberts and his colleagues developed a refactoring tool called the Smalltalk
Refactoring Browser. This refactoring browser allows the user to perform many interesting refactoring
automatically (e.g., Rename, Extract/Inline Method, Add/Remove Parameter). However, this early tool
was not popular because it was a stand-alone tool separate from the integrated development environment
(IDE). Developers found it inconvenient to switch back and forth between the IDE (develop code) and
Refactoring Browser (refactor code). Thus later refactoring tools have been integrated in the IDEs. The
following are refactoring tools for Java.
IntelliJ IDEA is an expensive commercial IDE. This tool also supports Rename and Move
Program Entities (e.g., package, class, method, field), Change Method Signature, Extract Method, Inline
Method, Introduce Variable, Introduce Field, Inline Local Variable, Extract Interface, Extract Super class,
Encapsulate Fields, Pull Up Members, Push Down Members and Replace Inheritance with Delegation.
RefactorIt RefactorIt is a commercial software that supports many automatic refactorings.
It can cooperate with Sun ONE Studio, Oracle 9i JDeveloper and Borland JBuilder. The
supported refactorings are: Rename, Move Class, Move Method, Encapsulate Field, Create Factory
Method, Extract Method, Extract Superclass/Interface, Minimize Access Rights, Clean Imports, Create
Constructor, Pull Up/Push Down Members.
JRefactory is a tool that is first developed by Chris Seguin. However, Mike Atkinson has taken
over the leadership role since late 2002. This tool allows easy application of refactoring by providing user
interface based on UML diagrams as visualization of Java classes. It can cooperate with JBuilder and
Elixir IDEs. JRefactory supports the following refactoring: Move Class, Rename Class, Add an Abstract
Super class, Remove Class, Push Up Field, Pull Down Field, Move Method.
 jFactor for Visual Age Java is a commercial product that provide a set of refactoring. Extract
Method, Rename Method Variables, Introduce Explaining Variable, Inline Temp, Inline Method, Rename
Method, Pull Up/Push Down Method, Rename Field, Pull Up/Push Down Field, Encapsulate Field,
Extract Super class/Interface.
Transmogrify Transmogrify is a Java source analysis and manipulation tool. This tool is under
development and currently is focused on the refactoring tool. It is available as a plug-in for JBuilder and
Forte4Java. It supports a limited set of refactorings such as Extract Method, Replace Temp with Query,
Inline Temp, Pull Up Field.
Eclipse is a generic development environment by IBM. It also has refactoring support and some
analysis. This project is open source. The current version of Eclipse (Helio version 3.6.1) supports many
types of refactorings which include Move Method, Rename Method, Encapsulate Fields and etc.
Microsoft Visual Studio Microsoft Visual Studio is an integrated development environment. It supports
many primitive refactorings.
Generally, refactoring tools provide a list of refactorings in which the user can choose from the
menu. Once the user chooses which refactoring to apply, the tool performs analyses in the background
checking the required conditions. If those conditions are met, then refactoring can be performed. A few
tools, like the refactoring support in Eclipse, allow the user to preview the resulting code before
committing changes to the code. The preview feature gives the user a better idea of which part of his code
will be affected by such a refactoring and whether it corresponds with his intention.
There are many refactoring tools for other programming languages like C++. For instance,
Xrefactory also known as xref is a refactoring browser for Emacs, XEmacs and jEdit. CppRefactory is
another open source refactoring tool that automates the refactoring process in a C++ project. Though the
refactoring framework was originally proposed for the object-oriented programming language, many
researchers apply the idea of refactoring to other language paradigms as well. Li and his colleagues
propose refactoring tool support for functional languages . Saadeh and Kourie developed a refactoring
tool for Prolog. The general idea is similar to that of object-oriented languages but the conditions and
mechanics are different.
Although most tools discussed in this research apply refactorings by directly manipulating the
source code, many software designers think about refactorings at the design level. Researchers who are
interested in design-level transformations include Griswold and Bowdidge . They state that it is rather
difficult to conceptualize program structure by just observing the program text. Instead of using program
text,a graphical representation of program structure is used as it permits direct manipulation of the
program structure at design level. Gorp et al. , Enckevort and Saadeh et al. and propose techniques to
apply refactorings to UML diagrams.
 We omit further discussion regarding design-level transformations, since our work uses source
code manipulation approach. Like Opdyke and Fowler, we believe that refactoring tool cannot be
completely automated. A good refactoring tool should give the developers the final authority. It must
interact with the developer because inferring design intent is difficult. Some refactorings may introduce a
design change which requires software developer's insights because he has the best knowledge of the
program context. A tool can facilitate the process by suggesting a set of refactorings and helps ensure that
each refactoring is applied correctly.
Code Smell Detection Tools
There are a number of tools that support automatic code inspection. The well-known C analyzer
LINT and its Java variant JLINT can check for type violations, null references, array bounds errors, etc.
These tools focus on improving code quality from a technical perspective. JDeodorant is another code
smell detection tool which specifically identifies type-checking bad smells in Java source code. Code
smells that the early version of JDeodorant can detect Replace Conditional with Polymorphism and
Replace Type Code with State/Strategy. JDeodorant, however, only identifies code smells. It does not
provide any suggestions or recommendations on how such smells should be removed. Recent version of
JDeodorant [31] also identifies God Classes, suggests where to apply Extract Class refactoring and allows
the programmer to perform class extraction in the process.
The work by Eva van Emden and Leon Moonen and RevJava are more closely related to this
work as they focus on improving code quality from a program design and programming practice
perspective. RevJava is a Java analysis tool that performs design review and and architectural
conformance checking. Based on predefined and user-defined design rules, the system analyzes Java byte
code, checks if any rules are violated and reports them to the user. However, RevJava is not suitable for
large software systems because it has no support for visualization of rule violations.
Emden and Moonen categorize code smells into two kinds of aspects: primitive smell aspects and
derived smell aspects. Primitive smell aspects can be observed directly from the code. Derived smell
aspects, on the other hand, are inferred from other aspects according to a set of inference rules. In this
architecture, the detection of primitive smell aspects and the inference of derived smell aspects are treated
as separate units, and consequently, they are extendable. The programmer can add new code smells by
extending the inference rules. Unlike RevJava, Emden's work analyzes Java source code because some
coding standards cannot be checked on bytecode, since the bytecode contains less information than the
original source code.

The code smells detection process is:

1) Find entities of interest, 2) Inspect them for primitive smells,
3) Store information in a repository 4) Infer derived smells from the repository.
After the smells have been detected, they are presented to the user by visualizing the source model using
graphs.
Refactoring and Type Constraints
Type constraints are usually used to type check the program. Some researchers adopt this idea
and add type constraints to the condition check in order to ensure behavior preservation in refactoring.
Tip et al. use type constraints for a set of refactorings that is related to generalization, e.g., Pull Up
Members and Extract Interface. The type constraints are used to verify the refactoring's preconditions.
Research work by Balaban et al. uses type constraints for library class migration [6]. All methods
in legacy classes (e.g., Hashtable and Vector) have been superseded by classes (HashMap and ArrayList
respectively) which provide similar functionalities except they allow unsynchronized access to their
elements. When replacing legacy classes with unsynchronized, synchronization wrapper. In their
research, a set of type constraint rules to migrate program that uses legacy class are defined. The
programmer must define a set of migration specifications. Type constraint rules are generated from the
given program and migration specifications. The runtime of the analysis is exponential. They also provide
an algorithm for Escape Analysis that is used to check for thread safety.
It is inarguable that type constraints is useful for many refactorings. However, its usage restricts
to only refactorings that involve types and those that could introduce type violation if applied carelessly.
Steve et al., described analysis of code smells. They used bad smell taxonomy described and a
bespoke software tool to find number of refactoring required for each of 22 bad smells. According to his
analysis, Bloaters is the smell category that needs most effort because it requires larger number of
refactoring to remove from code. The Change Preventers needs least effort because it requires lowest
average number of refactoring to eradicate from code. They claimed that bad smells are deceptive in
nature mean that they hide the real effort that would be required to remove that smell when nested
refactoring are involved. Bad smells that requires most effort to remove are best understood by developers
and, conversely, bad smells requires less effort to remove are least understood by developers.
In Foutse et al., presented that classes with code smells are more change prone then the classes
without code smells. They further showed that the correlation between particular type of code smell and
change proneness. They used DECORE approach to detect code smells and applied different
mathematical techniques to conclude the results. Two systems from different domains were selected for
experimentation. Both were open source systems namely Azureus and Eclipse .
 From 13 releases of Eclipse and 9 releases of Azureus they showed that classes with bad smells
are more change prone then the classes without bad smells. They further proved that a particular kind of
bad smells lead to change-proneness.
However this study does not concern the type and amount of change and it is limited to only two
systems. If it is generalized to more systems it may give different outcomes.
Evolution of three bad smells on two open source system was studied in . Consecutive version of jFlex
and jFreechart were taken into account to perform the analysis. The bad smells namely Long method,
Feature envy and State checking were extracted using JDeodorant. The result showed that the number of
bad smells in system increase as the system evolves over the time; many of the bad smells remain in the
code up to latest versions of the system; some of the bad smells that are removed were not a result of
targeted refactoring application rather they are removed in an effort of adaptive maintenance.
Fontana et al., presented a report on on smell detection tools. They stated result of six bad smell detection
tools; experimentation was performed on 5 versions of Gantt Project . As none of the bad smell shared by
all tools, that’s why they perform their analysis on a subset of the tool. On the basis of their experiments
and results they concluded that; main critical aspect is to have no access to detection rules and metrics
thresholds. They proposed that bad smell detection tools should have the possibility to set and change the
metrics threshold.
Wake classified bad smells into two categories: bad smells within classes and bad smells between
classes. Meszaros10 classified test smells into code smells, behavior smells, and project smells.
Mantyla11 analyzed the correlations among bad smells by investing the frequency with which each pair
of bad smells appears in the same module.
They found that bad smells within the same category are more likely to appear together. The
work aimed to simplify the comprehension of bad smells, instead of refactoring activities.
Pietrzak and Walter12 investigated the inter smell relationships to facilitate the detection of bad smells.
They argued that detected or rejected bad smells might imply the existence or absence of other bad
smells. The design of software systems can exhibit several problems which can be either due to inefficient
analysis and design during the initial construction of the software or sometimes may be due to software
ageing since software quality degenerates with time.
According to Fowler, design problems appear as ―bad smells‖ at code or design level and the
process of removing them is called refactoring where the software structure is improved without any
modification in the behavior. It can be briefly defined as ―Restructuring of internal structure of object
oriented software to improve the quality while the software’s external behavior remains unchanged‖ –
Fowler Refactoring improves the design of software and makes software easier to understand. It also
helps us to find bugs.
 Bad smells can be detected using various kinds of automated tools. The problem behind this is
clear, where the smell being refactored may have dependency In increasing or resolving some other kind
of smell which in turn results in increased effort and time. A smell being resolved may affect the presence
of an existing smell or introduces some more conflicts into the system.
REFACTORING METHODS
 Push down method:
”Behavior on a super class is relevant only for some of its subclasses. The method is
moved to those subclasses.
 Pull up Method:
”You have methods with identical results on subclasses. In this case, the methods should
be moved to the super class.
 Pull up field:
”Two subclasses have the same field. In this case, the field in question should be moved
to the super class.
 Move field:
”A field is, or will be, used by another class more than the class on which it is defined.
 Rename Method:
A method is renamed to make its purpose more obvious.
 Rename Field:
A field is renamed to make its purpose more obvious.
 Move Method:
”A method is, or will be, using or used by more features of another class than the class on
which it is defined.
REFACTORING PROCESS
Refactoring can be divided into a number of steps as shown below
1. Identify where the software needs to be refactored.
2. Determine which refactoring need to be applied to the identified places.
3. Guarantee that the applied refactoring preserves behavior.
4. Apply the refactoring.
5. Assess the effect of the refactoring on the quality characteristics of the software or the process.
6. Maintain the consistency between the refactored program code and other software artifacts.
APPLICATIONS OF REFACTORING
Validity
Henderson-Sellers define two types of validity: internal and external. Internal validity addresses
how well a measure captures the \meaning" of things that we want to measure. Furthermore, a
new measure should correlate with the old one. It is evident that our measure relates to other
existing measures. A class with many instances of feature envy implies that it is highly coupled
with other classes. External validity relates to generalization issues. In other words, the metric
must be generalized beyond the samples that have been measured. Generally, external validity
cannot be experimentally determined and it can hardly be achieved. Our metric is originally
designed for Java. It is not applicable to other programming language paradigms but
it can be adapted for use in other object-oriented programming languages.
Reliability
A metric is reliable if it produces consistent results. Consistency involves stability and
equivalence. Stability means it is deterministic, in other words produces the same results given
the same input. In our case, provided that the same w and the same x are used on the same input,
the metric will produce the same results. Moreover, two feature envy instances have equivalent
level of severity, if the computed values
are the same.
Robustness
Tsai et al. define robustness as the ability to tolerate incomplete information. Furthermore, the
robustness is determined based on how well it can handle incorrect input. In this case, the
information required for the metric is the source code. The only requirement is that the given
source code must not have any compile errors. Our metric does not require the whole program so
it is robust to some degree.
Practicality
The metric must be informative. Jones believes a useful metric should be language independent
and applicable during the early stages of the development process. However, due to the nature of
feature envy which happens after the implementation, it is impossible to come up with a metric
that determines feature envy during the design phase. Feature envy can only be revealed after the
code has been written.
CONCLUSION
A new metric for feature envy is discussed in this chapter. The values of our metric can be
uniquely interpreted in terms of the severity of the problem. Since the values computed by our
metric are in the range of 0 and 1, it is easy to compare a particular value with other values. We
also explained that an analysis can be combined with the metric to improve the accuracy of the
results. It is worth noting that other research works on feature envy detection . Oliveto et al.
introduces the concept of method friendships which analyzes both structural and conceptual
relationships between methods. Other works, though not related to feature envy detection, also
attempt to retrieve semantic information from the source code. Some researchers use information
retrieval technique called Latent Semantic Indexing to extract identifiers and comments . Others
use natural language processing techniques and introduce the LORM metric . A work by Bavota
et al. proposes a technique to extract class but we believe that their approach can be modified and
applied to detect feature envy, since their approach also includes cohesion metric.
REFERENCES
 Aqris. RefactorIt. http://www.refactorit.com, 2001.
 Giuliano Antonioil, Umberto Villano, Ettore Merlo, and Massimiliano Di Penta. Analyzing
cloning evolution in the linux kernel. Information & Software Technology,
 Cyrille Artho and Armin Biere. Applying static analysis to large-scale multithreaded Java
programs. In Proceedings of the 13th Australian Software Engineering Conference
 B. S. Baker. On finding duplication and near-duplication in large software systems. In WCRE
'95: Proceedings of the Second Working Conference on Reverse Engineering. IEEE Computer
Society, Washington, DC, USA, 1995.
 James M. Bieman and Byung-Kyoo Kang. Measuring design-level cohesion. Software
Engineering, 24(2):111{124, 1998.