Code Smell History

8/10/2019 Code Smell History

http://slidepdf.com/reader/full/code-smell-history 1/67

Code Smell Research:

History and Future Directions

SOEN 691C - Fall 2014 1

Nikolaos Tsantalis

Computer Science & Software Engineering



Changes aiming to improve the future

maintainability and reliability of the

software system.

SOEN 691C - Fall 2014 2



3



• Refactoring Object-oriented Frameworks,

University of Illinois at Urbana-Champaign

– Introduced the concept of refactorings as behavior-

preserving program restructuring operations.

– Introduced the concept of preconditions as

conditions that should be examined to determine

whether a refactoring can be applied safely.

SOEN 691C - Fall 2014 4



SOEN 691C - Fall 2014 5



SOEN 691C - Fall 2014 6



Duplicated Code:

“If you see the same code

structure in more than one

place, … find a way to unify

them.”

SOEN 691C - Fall 2014 7



SOEN 691C - Fall 2014 8

http://www.industriallogic.com/blog/smells-to-refactorings-cheatsheet/



SOEN 691C - Fall 2014 9



SOEN 691C - Fall 2014 10



SOEN 691C - Fall 2014 11



SOEN 691C - Fall 2014 12



SOEN 691C - Fall 2014 13



Code smell definition for Inappropriate Interface

inappropriateInterface(?class,?interface,?subclasses) :-

findall(<?itf,?scs>,

commonSubclassInterface(?class,?itf,?scs),

?result),

removeDuplicates(?result,?nodups),

member(<?interface,?subclasses>,?nodups)

SOEN 691C - Fall 2014 14



SOEN 691C - Fall 2014 15



SOEN 691C - Fall 2014 16



SOEN 691C - Fall 2014 17



SOEN 691C - Fall 2014 18



• Treat the improvement of object-oriented design

as a search problem in the space ofalternative designs

• The move in the search space is achieved bymodeling refactorings (inheritance-related)

• Apply search algorithms using QMOOD as the

fitness function (rank alternative designs)• The outcome is a sequence of refactorings

leading to the optimal design

SOEN 691C - Fall 2014 19



SOEN 691C - Fall 2014 20



SOEN 691C - Fall 2014 21



SOEN 691C - Fall 2014 22



SOEN 691C - Fall 2014 23



SOEN 691C - Fall 2014 24



Many code smell definitions are based on

historical change information

– Shotgun Surgery: When every time you make a

kind of change, you have to make a lot of littlechanges to a lot of different classes.

– Parallel Inheritance Hierarchies: When every time

you make a subclass of one class, you also have tomake a subclass of another.

SOEN 691C - Fall 2014 25



SOEN 691C - Fall 2014 26



SOEN 691C - Fall 2014 27



• 12 code smells

• 6 Professional developers were hired to

implement change requests

• 4 medium-sized Java systems with known

code smells

• 4 weeks of development

• Daily interviews and think-aloud sessions

SOEN 691C - Fall 2014 28



SOEN 691C - Fall 2014 29



SOEN 691C - Fall 2014 30



Advantages:

Feasible and behavior preserving solutions

to design problemsRanking and prioritizing solutions based on

their expected effect on design quality

A holistic approach for preventivemaintenance

SOEN 691C - Fall 2014 31



1. Identify places where software should be refactored

(known as bad smells).

2. Determine which refactoring(s) should 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 qualitycharacteristics of the software.

6. Maintain the consistency between the refactored code

and other software artifacts.

SOEN 691C - Fall 2014 32



SOEN 691C - Fall 2014 33



SOEN 691C - Fall 2014 34



• The entity set of an attribute attr {the methods

accessing attr }

• The entity set of a method m {the attributes and

methods accessed by m}• The entity set of a class C {the attributes and

methods that belong to C }

, = 1 − ∩

∪

SOEN 691C - Fall 2014 35



=

, ∈

∈

, ∉

∉

SOEN 691C - Fall 2014 36

cohesion

coupling



SOEN 691C - Fall 2014 37



Context

+ method() {state.method();

}

- type : int- STATE_A : int = 1- STATE_B : int = 2

SOEN 691C - Fall 2014 38

State

+method()

StateB

+method() {

}

StateA

+method() {

}

Context

+ method() {

}

- state : int- STATE_A : int = 1- STATE_B : int = 2

doStateA();

if state == STATE_A

else if state == STATE_B

doStateB();

state



SOEN 691C - Fall 2014 39



SOEN 691C - Fall 2014 40



For every variable declared in a method:

1. Find the statements that update its value or state

2. Compute the slices starting from these statements

3. The union of the computed slices contains thecomplete computation of the variable

4. Find whether some statements in the union of sliceshave to be duplicated after extraction

5. Examine whether the duplication of statementspreserves the program behavior

SOEN 691C - Fall 2014 41



SOEN 691C - Fall 2014 42



SOEN 691C - Fall 2014 43



SOEN 691C - Fall 2014 44



SOEN 691C - Fall 2014 45



SOEN 691C - Fall 2014 46



SOEN 691C - Fall 2014 47



SOEN 691C - Fall 2014 48



SOEN 691C - Fall 2014 49



SOEN 691C - Fall 2014 50

Since the beginning of 2011 …



SOEN 691C - Fall 2014 51



SOEN 691C - Fall 2014 52



SOEN 691C - Fall 2014 53



• “Debt” is the effect of incomplete, immature,or inadequate maintenance activities

• Delayed tasks may bring a short-term benefit (higher productivity, shorter release time)

• Might have to be paid back in the future with

“Interest” (increased effort)

• “Principal” is the effort to pay off the debt

SOEN 691C - Fall 2014 54





SOEN 691C - Fall 2014 56



SOEN 691C - Fall 2014 57





• So far, we used

– Static source code analysis

– Semantic analysis

– Change history analysis

SOEN 691C - Fall 2014 59



SOEN 691C - Fall 2014 60



Every code smell involves a certain risk

for future maintainability

SOEN 691C - Fall 2014 61



• Likelihood of occurrence of the risky event

• Exposure of the system to the event

•Consequence of the event

SOEN 691C - Fall 2014 62



• Risky events changes driven by code smells

– Ex. 1: Fixing the same bug in a clone group

– Ex. 2: Making a method more “envy” to another class

• Intuition: code that changes frequently due to

a design flaw imposes a high risk to the

maintainability of a system

• Likelihood proneness to code smell driven

changes (estimated from the history of changes)

SOEN 691C - Fall 2014 63



• Intuition: the more extensively a module is used,

the more extensive the propagation of code

smell driven changes to dependent modules

• Exposure the number and strength of

incoming dependencies (estimated from static

and dynamic analysis)

SOEN 691C - Fall 2014 64



• Consequence cost of code smell driven

changes (effort, time, money).

From the opposite perspective:

• Consequence effect of removing the code

smell.

•

Estimated by computing the impact of thecorresponding refactoring on metrics.

SOEN 691C - Fall 2014 65



Given a set of different types of refactoringopportunities in a software system

• Conflicts

• Dependencies

SOEN 691C - Fall 2014 66



Visit our project at

Documents

Code Smell History