Final Year Project Proposal

Code smell detection using JAVA

<Submitted by>

AZHAR ZAFAR
HAMZA REHMAN
MUHAMMAD JAHANGIR
MUHAMMAD USMAN JUNAID

<Supervisor>

ISRAR ALI

<Coordinator>

DR. ASIM ALI RIZVI

Literature Review:

Introduction:
Ever increasing maintenance costs are often a consequence of poor software design,
bad coding style, and undisciplined practices. Among the consequences of such a
scenario, error proneness stands out. Code smells are symptoms in source code that
are indicative of bad style and/or design. They violate good practices and design
principles, affecting understanding and maintenance and promoting a negative impact
on software quality and ease of evolution.

Several tools support the detection of code smells in programs written in different
languages. In this project, we review published studies by means of a systematic
literature review (SLR). From the 18 selected studies, 16 studies reported the influence
of code smells on the occurrence of bugs. Based on the analysis of these 16 studies,
we identified 24 code smells with greater influence on bugs, specially God Class,
Comments, Message Chains, and Feature Envy code smells. It was also possible to
identify tools, techniques, and resources that were used by several studies. We
identified the use of 25 tools, where 9 were focused on the detection of code smells,
and the other 16 were focused on some stage of the empirical study reported in the
study. We also identified the adoption of 24 techniques and resources such as metrics,
heuristics, and scripts to perform the analysis presented in the selected studies.

Code Smell and Refactoring:

The term “Code Smell” appears to have been coined by Kent, Beck on WardsWiki in the
late 1990s (Roperia, 2009). Let us consider an example to understand the meaning of
code smell. An unusual long method in an object-oriented programming language like
Java might indicate a “Long Method” smell. It indicates lack of understanding of or
disregard for a proper object design and the use of simple procedural programming in
an object-oriented language. This is a very common sign of code smell in object-
oriented language. In rare cases this could be normal, but most likely such long-winded
methods perform too much functionality thus making it difficult to understand and
maintain. To solve this problem, such methods should first be split into smaller methods
or functions to promote reusability. As a second step, if an object-oriented language is
being used, the object model should be reviewed as well. However, that does not mean
that a long method is always a code smell problem – it is most likely an indicator of a
design issue in the software than of a problem.

Refactoring is a solution to the problem which code smell indicates. It is the

implementation technique used to apply a better design to an existing, fully or partially
functional, software program. It does present a larger upfront cost compared to quick
fixes and patchwork; however, its long-term payoff can be significant. When contrasted
with a complete software rewrite, refactoring is a cost effective option. Large software
usually goes through a long cycle of development and testing. A complete rewrite
means another long cycle of development and testing. Refactoring existing code offers
a way of improving the software design and removing code smells without actually
rewriting the entire code from scratch.

If a method is long, splitting it into smaller methods is actually a refactoring technique

that improves the design of the source code, making it easier to understand, enhance,
and maintain. To better understand and emphasize the importance of refactoring, we
can take “Duplicate Code” smell as an example. Duplicate code is not just a design
issue; it also leads to incorrect calculations and redundant code and data. Therefore, to
ensure the software works as per specification, it is necessary to refactor duplicate lines
of code into smaller, more manageable methods and invoke these methods from the
client code. Thus, the refactoring technique improves the structure of the code
dramatically while retaining its functionality.

Correct detection of code smells is the main prerequisite to create a refactoring plan.
The correct implementation of the plan will improve the quality of code. The refactoring
process depends on the smells found in the system, and it directly affects software
maintenance cost.

Fowler and Beck defined code smells as symptoms in the source code indicating that
there may be deficiencies in the design and/or programming style of a software system.
They proposed a catalog of 22 code smells to be used as indicators of poor design and
implementation choices. As a catalog, these code smells can also serve as a vehicle to
express what should be avoided to obtain good style and modularity in object-oriented
programming. Code smells usually appear during change activities and when software
bugs are fixed. To tackle this problem, approaches and tools were implemented to
support the identification of code smells.

Table 1. List of Code Smells according to Fowler and Corresponding Alternative Names.

Code Smells (Fowler) Alternative Name

Duplicated Code Clones (S15), Code clones (S1, S17)
Comments Comments Line (S12)
Long Method God Method (S4)
Long Parameter List Long Parameter List Class (S5)

Refactoring Tools:

In early 1990s, Don Roberts and his colleagues developed a refactoring tool called the
Smalltalk Refactoring Browser [76]. This refactoring browser allows the user to perform
many interesting refactoring is 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:
This is an expensive commercial IDE. This tool also supports Rename and Move
Program Entities (e.g., package, class, method, and field), Change Method Signature,
Extract Method, Inline Method, Introduce Variable, Introduce Field, Inline Local Variable,
Ex-tract Interface, Extract Superclass, Encapsulate Fields, Pull-up Members, Pushdown
Members and Replace Inheritance with Delegation.

RefactorIt:
RefactorIt is a commercial software that supports many automatic refactoring’s. It can
cooperate with Sun 1 Studio, Oracle 9i JDeveloper and Borland JBuilder. The supported
refactoring’s are: Rename, Move Class, Move Method, Encapsulate Field, Create
Factory Method, Ex-tract Method, Extract Superclass/Interface, Minimize Access
9Rights, Clean Imports, Create Constructor, and Pull Up/Push down Members.

JRefactory:
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
refactorings 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’s: Move Class, Rename Class, Add an Abstract Superclass,
Remove Class, Push up Field, Pull Down Field, Move Method.

JFactor:
JFactor for VisualAge Java is a commercial product that provide a set of refactoring’s.
Extract Method, Rename Method Variables, Introduce Explaining Variable, Inline Temp,
Inline Method, Re-name Method, Pull Up/Push Down Method, Rename Field, and Pull
Up/Push Down Field, Encapsulate Field, Extract Superclass/Interface.

Eclipse:
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 refactoring’s which include Move Method,
Rename Method, Encapsulate Fields and etc.

My Project (Code Smell detection using JAVA):

Our tool, analyzes Java source code to detect code smell automatically. CSD’s
functionality is limited to the detection of five code smells: “Switch Cases,” “Data Class,”
“Middle Man,” “Long Parameter List,” and “Long Method”. These code smells will be
discussed in detail later in this section. In cases where “Data Class “and “Long Method”
smells are detected, JSD provides an option to refactor the code. Refactoring
techniques are suggested for “Switch Cases,” “Middle Man,” and “Long
Parameter List” smells.
Comparison:

Refactoring Tools
Technique/ IntelliJ RefactorIt JRefactory JFactor Eclipse My Project
Method IDEA (Code Smell
detection
using JAVA)
Extract Yes Yes No Yes Yes Yes
Method
In Line Yes No No Yes Yes Yes
Method
Replace No No No No No Yes
Method
Replace
temp with No No No No No Yes
Query
Move No Yes Yes No Yes Yes
Method
Push Down Yes Yes Yes Yes Yes Yes
Method
Rename Yes Yes Yes Yes Yes No
Method
Encapsulate Yes Yes No Yes No Yes
Field
Pull Up Yes Yes Yes Yes Yes No
Method
Create No Yes No No No No
Constructor
Extract Super No
classes Yes Yes No Yes Yes
Replace
Parameter
with Explicit No No No No No Yes
Methods
Replace
Delegation Yes No No No No Yes
with
Inheritance
Abstract
Super Class No No Yes No No No
Remove No No Yes No No Yes
Middle Man
Replace
Conditional
with No No No No No Yes
 polymorphis
m
Replace type No No No No No Yes
code
Hide Method No No No No No Yes
Introduce
parameter No No No No No Yes
object
Preserve
Whole object No No No No No Yes

Summary:
Code smell detection is a very complex procedure. Careful design analysis of the
Software system is required for detecting the code smell. It is believed that human
intuition is the best way to detect code smell (Roperia, 2009); however, detection
becomes more difficult as system size increases. This creates the need for automated
detection, especially for larger systems. The automatic detection of code smell can be
done using statistical data analysis. However, the detection of all of the 22 smells using
statistical data is not possible (Bhalla, 2009).

Replace method with object

Decompose Conditional
Replace Setting method