SlideShare uma empresa Scribd logo
1 de 91
Baixar para ler offline
BAD CODE SMELLS
LINGI2252 – PROF. KIM MENS
* These slides are part of the course LINGI2252 “Software Maintenance and Evolution”,
given by Prof. Kim Mens at UCL, Belgium
*
A. INTRODUCTION
LINGI2252 – PROF. KIM MENS
Bad Smells in Code
Reference
Martin Fowler, Refactoring: Improving the Design of Existing Code.

Addison Wesley, 2000. ISBN: 0201485672
Chapter 3: Bad Smells in Code, by Kent Beck and Martin Fowler
Overview of this presentation
Introduction
A classification of bad smells, including a 

detailed illustration of some of them
Conclusion
3
Introduction
Bad Smells = “bad smelling code”
indicate that your code is ripe for refactoring
Refactoring is about
how to change code by applying refactorings
Bad smells are about
when to modify it
4
Bad Smells
Allow us to identify
what needs to be changed in order to improve the code
A recipe book to help us choose the right refactoring pattern
No precise criteria
More to give an intuition and indications
Goal : a more “habitable” code.
5
Side note: Habitable code
Habitable code is code in which developers feel at home

(even when the code was not written by them)
Symptoms of inhabitable code include

overuse of abstraction or inappropriate compression
Habitable code should be easy to read, easy to change
Software needs to be habitable because it always has to change
[Richard P. Gabriel, Patterns of Software: Tales from the

Software Community, Oxford University Press, 1996]
6
B. CLASSIFICATION OF BAD SMELLS

INCLUDING A DETAILED DISCUSSION OF 5 OF THEM
LINGI2252 – PROF. KIM MENS
An Online Classification
https://sourcemaking.com/refactoring
8
DISCLAIMER:

SEVERAL CARTOONS SHOWN IN
THIS PRESENTATION WERE
BORROWED FROM THAT SITE
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments
9
Bad Smells : Alternative Classification
Bloaters are too large to handle
Object-orientation abusers

do not respect OO principles
Change preventers stand in the way of change
Dispensables are things you could do without
Couplers contribute to excessive coupling between
classes
Other smells
10
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments
11
The top crime
12
Code duplication
Code duplication
Duplicated code is the number 1 in the stink parade !
We have duplicated code when we have

the same code structure in more than one place
Why is duplicated code bad?
A fundamental rule of thumb :

it’s always better to have a unified code
13
14
Code duplication example 1
public double ringSurface(r1,r2) {
// calculate the surface of the first circle
double surf1 = bigCircleSurface(r1);
// calculate the surface of the second circle
double surf2 = smallCircleSurface(r2);
return surf1 - surf2;
}
private double bigCircleSurface(r1) {
pi = 4* ( arctan 1/2 + arctan 1/3 );
return pi*sqr(r1);
}
private double smallCircleSurface(r2) {
pi = 4* ( arctan 1/2 + arctan 1/3 );
return pi*sqr(r2);
}
15
Code duplication example 2
Class
method1
method2
method3
code
code
code
code
Same expression in two
or more methods of the
same class
16
Code duplication example 3
methodA
code
Class
methodB
code
SubClassA SubClassB
Same expression in two
sibling classes
inherits
from
17
Code duplication example 4
methodA
code
methodB
code
ClassA ClassB
Same expression in two
unrelated classes
18
Code duplication: Refactoring Patterns (1)
public double ringSurface(r1,r2) {
// calculate the surface of the first circle
double surf1 = surface(r1);
//calculate the surface of the second circle
double surf2 = surface(r2);
return surf1-surf2;
}
private double surface(r) {
pi = 4* ( arctan 1/2 + arctan 1/3 );
return pi*sqr(r); }
Extract method
+
Rename method
19
Code duplication: Refactoring Patterns (2)
Class
method1
method2
method3
code
code
code
code
Same expression in two or
more methods of the same class
Extract
method
Class
method1
method2
Call methX()
Call methX()
Call methX()
method3
Call methX()
methX()
xcodeReturn
20
Code duplication: Refactoring Patterns (3)
Same expression in
two sibling classes
Extract method
+
Pull up field
Same code
Extract method
+
Form Template
Method
Similar
code
Substitute
algorithm
Different
algorithm
Class
SubClass A SubClass B
21
Code duplication: Refactoring Patterns (4)
methodA
ClassA ClassB
Same expression
in two unrelated classes
Call ClassC.methX()
methodB
Call ClassC.methX()
methX()
codereturn
Extract
class
Extract
class
code code
22
Code duplication: Refactoring Patterns (4’)
methodA
ClassA ClassB
Same expression
in two unrelated classes
Call ClassC.methXcode()
methodB
Call ClassA.methodA()
If the method really belongs in one
of the two classes, keep it there
and invoke it from the other class
code code
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments
23
Large Class
A large class is a class that

is trying to do too much
Often shows up as too many instance variables
Use Extract Class or Extract Subclass to bundle
variables
choose variables that belong together in the extracted class
common prefixes and suffixes may suggest which ones may
go together, e.g. depositAmount and depositCurrency
24* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Large Class
A class may also be too large in the sense that it has too much code
likely some code inside the class is duplicated
solve it by extracting the duplicated code in separate methods
using Extract Method
or move part of the code to a new class, using Extract Class
or Extract Subclass
if need be, move existing or extracted methods to another class
using Move Method
25
Long Parameter List
In procedural programming
languages, we pass as parameters
everything needed by a subroutine
Because the only alternative is
global variables
With objects you don’t pass
everything the method needs
26* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Long Parameter List
Long parameter lists are hard to understand
Pass only the needed number of variables
Use Replace Parameter with Method when
you can get the data in one parameter by making
a request of an object you already know about
27
Lazy Class
Each class cost money (and brain cells) to maintain and understand
A class that isn't doing enough to pay for itself should be eliminated
It might be a class that was added because of changes that were
planned but not made
Use Collapse Hierarchy or Inline Class to eliminate the class.
Person
name
getTelephoneNumber
Telephone Number
areaCode

number
getTelephoneNumber
Person
name

areaCode

number
getTelephoneNumber
28* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Data Class
Classes with just fields, getters, setters and nothing else
If there are public fields, use Encapsulate Field
For fields that should not be changed use Remove
Setting Method
29* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Long Method
Object programs live best and longest with short methods
New OO programmers feel that OO programs are endless sequences
of delegation
Older languages carried an overhead in subroutine calls which deterred
people from small methods
There is still an overhead to the reader of the code because you
have to switch context to see what the subprocedure does (but the
development environment helps us)
Important to have a good name for small methods
Rename Method
30
Long Method
The longer a procedure is, the more difficult it is to
understand what the code does
More difficult to read
Bad for maintainability
More difficult to make modifications
To summarise… less habitable !
31* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Long Method
Too avoid too long methods, decompose methods in many
small ones
Heuristic: whenever you feel the need to comment
something, write a method instead
containing the code that was commented
named it after the intention of the code

rather than how it does it
Even a single line is worth extracting if it needs explanation
32
Long Method: Example
33
void printOwing() {
Enumeration e = _orders.elements();
double outstanding = 0.0;
// Print banner

System.out.println(“******************“);

System.out.println(“***** Customer *****“);

System.out.println(“******************“);
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
// Print details

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
Example was
shortened to
fit on 1 slide
Long Method: Refactoring patterns
99% of the time, all we have to do to shorten a method is
Extract Method
Find parts of the method that seem to go together nicely and
extract them into a new method.
It can lead to problems…
Many temps : use Replace Temp with Query
Long lists of parameters can be slimmed down with
Introduce Parameter Object
34
Long Method: Refactoring patterns
But how to identify the clumps of code to extract ?
Look for comments…
A block of code with a comment that tells you what it is
doing can be replaced by a method whose name is based on
the comments
Loops also give signs for extractions…
Extract the loop and the code within the loop into its own
method.
35
Long Method Example revisited
36
void printOwing() {
Enumeration e = _orders.elements();
double outstanding = 0.0;
// Print banner

System.out.println(“******************“);

System.out.println(“***** Customer *****“);

System.out.println(“******************“);
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
// Print details

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
Long Method Example revisited
37
void printOwing() {
Enumeration e = _orders.elements();
double outstanding = 0.0;
// Print banner

System.out.println(“******************“);

System.out.println(“***** Customer *****“);

System.out.println(“******************“);
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
// Print details

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
Long Method Example revisited
38
void printOwing() {
Enumeration e = _orders.elements();

double outstanding = 0.0;
printBanner();
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
// Print details

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
void printBanner() {

System.out.println(“******************“);

System.out.println(“***** Customer ****“);

System.out.println(“******************“);

}
1.

Extract Method

Trivially easy !
Long Method Example revisited
39
void printOwing() {
Enumeration e = _orders.elements();

double outstanding = 0.0;
printBanner();
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
// Print details

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
void printBanner() {

System.out.println(“******************“);

System.out.println(“***** Customer ****“);

System.out.println(“******************“);

}
Long Method Example revisited
40
2.

Extract Method

Using Local Variables
void printOwing() {
Enumeration e = _orders.elements();

double outstanding = 0.0;
printBanner();
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
printDetails(outstanding);

}
void printDetails(double outstanding) { 

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
void printBanner() { … }
Long Method Example revisited
41
void printOwing() {
Enumeration e = _orders.elements();

double outstanding = 0.0;
printBanner();
// Calcultate outstanding

While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

outstanding += each.getAmount();

}
printDetails(outstanding);

}
void printDetails(double outstanding) { 

System.out.println(“name: “ + _name);

System.out.println(“amount” + outstanding);

}
void printBanner() { … }
Long Method Example revisited
42
3.

Extract Method
Reassigning a Local
Variable
void printOwing() {
printBanner();
double outstanding = getOutstanding();
printDetails(outstanding);

}
double getOutstanding() {
Enumeration e = _orders.elements();

double result = 0.0;
While (e.hasMoreElements()) {

Order each = (Order) e.nextElement();

result += each.getAmount();

}

return result;

}
void printDetails(double outstanding) {…}
void printBanner() { … }
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments
43
Coupling and cohesion
Coupling is the degree to which different software
components depend on each other
Cohesion is the degree to which the elements within a
software module belong together
Low cohesion and tight coupling are bad smells (why?)
44
Inappropriate Intimacy
Pairs of classes that know too much
about each other's private details
Use Move Method and Move
Field to separate the pieces to
reduce the intimacy
If subclasses know more about their
parents than their parents would like
them to know
Apply Replace Inheritance
with Delegation
45* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Data Clumps
A certain number of data items in lots of places
Examples: fields in a couple of classes, parameters in many
method signatures
Ought to be made into their own object
When the clumps are fields, use Extract Class to turn them
into an object
When the clumps are parameters, use Introduce Parameter
Object to slim them down
46
Feature Envy
When a method seems more interested in a class
other than the one it actually is in
47* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Feature Envy
In other words, When a method invokes too many times
methods on another object to calculate some value
Why is it bad to invoke a zillion times methods from
another class?
Because, in general, it is not logical from an OO
point of view.
Put things together that change together !
48
Feature Envy: Example (1)
public Void mainFeatureEnvy () {
OtherClass.getMethod1();
OtherClass.getMethod2();
OtherClass.getMethod3();
OtherClass.getMethod4();
}
public Void getMethod1 () { … }
public Void getMethod2 () { … }
public Void getMethod3 () { … }
public Void getMethod4 () { … }
OtherClass
49
Feature Envy: Refactoring Patterns (1)
First solution : Move Method
Public Void getMethod1 () { … }
Public Void getMethod2 () { … }
Public Void getMethod3 () { … }
Public Void getMethod4 () { … }
Public Void mainFeatureEnvy () {
getMethod1();
getMethod2();
getMethod3();
getMethod4();
}
OtherClass
Could we use
Extract method ?
Yes ! If only a part
of the method
suffers from envy
50
Feature Envy: Example (2)
Public Void mainFeatureEnvy () {
Class1.getMethod1();
Class1.getMethod2();
Class2.getMethod3();
Class2.getMethod4();
}
Public Void getMethod1 () { … }
Public Void getMethod2 () { … }
Class1
Public Void getMethod3 () { … }
Public Void getMethod4 () { … }
Class2
?
51
Feature Envy: Refactoring Patterns (2)
Use the same method as the first example :
Extract Method or Move Method
To choose the good class we use the
following heuristic :
determine which class has most of the data and
put the method with that data
52
Shotgun Surgery
When making one kind of change requires many
small changes to a lot of different classes
53* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Shotgun Surgery
Hard to find all changes needed; easy to miss an
important change
Use Move Method and Move Field to put all
change sites into one class
Put things together that change together !
If a good place to put them does not exist, create
one.
54
Parallel Inheritance Hierarchies
Special case of Shotgun Surgery
Each time I add a subclass to one hierarchy, I need
to do it for all related hierarchies
Use Move Method

and Move Field
55* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments
56
Message Chains
A client asks an object for another object who then asks
that object for another object, etc.
Bad because client depends on the structure of the
navigation
Use Extract Method and Move Method to break
up or shorten such chains
57* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Middle Man
Objects hide internal details (encapsulation)
Encapsulation leads to delegation
It is a good concept but...
Sometimes it goes to far…
58
Middle Man
Real-life example:
You ask a director whether she is free for a
meeting
She delegates the message to her secretary that
delegates it to the diary.
Everything is good… but, if the secretary has
nothing else to do, it is better to remove her !
59
Middle Man
If a class performs only one
action, delegating work to
other classes, why does it
exist at all?
Sometimes most methods
of class just delegate to
another class
60* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Middle Man: Example
61
class Person

Department _department;

public Person getManager() {

return _department.getManager();

}
class Department

private Person _manager;

public Department (Person manager) {

_manager = manager; }

public Person getManager() {

return _manager(); }

}
The class Person is hiding the Department class.
To find a person’s manager, clients ask :

Manager = john.getManager();
and the person then needs to ask :

_department.getManager();
client class
Person
getManager()
Department
getManager()
62
Middle Man: Refactoring
Remove Middle
Man
client class
Person
getDepartment()
Department
getManager()
client class
Person
getManager()
Department
getManager()
63
Middle Man: Refactoring
Remove Middle Man…
First step : Create an accessor for the delegate.
class Person {

Department _department;

public Person getManager() {

return _department.getManager(); }

public Department getDepartment() {

return _department; }

}
client class
Person
getManager()
getDepartment()
Department
getManager()
64
Middle Man: Refactoring
Second step : For each client use of a delegated method,
remove the method from the middle man and replace the
call in the client to call a method directly on the delegate
Last step : Compile and test.
client class
Person
getManager()
getDepartment()
Department
getManager()
client class
Person
getManager()
getDepartment()
Department
getManager()
Manager = john.getDepartment().getManager();
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments
65
Switch Statements
Switch statements (“cases”)
often cause duplication
adding a new clause to the switch requires finding

all such switch statements throughout your code
OO has a better ways to deal with actions depending on types:
polymorphism !
Use Extract Method to extract the switch statement and then Move
Method to get it into the class where polymorphism is needed.
Then use Replace Conditional with Polymorphism after you
setup the inheritance structure.
66* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Primitive Obsession
Characterised by a reluctance

to use classes instead of

primitive data types
The difference between classes and primitive types is
hard to define in OO
Use Replace Data Value with Object on individual
data value.
Use Extract Class to put together a group of fields
67* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Bad Smells : Classification
The top crime
Class / method organisation
Large class, Long Method, Long Parameter List, Lazy Class, Data Class, …
Lack of loose coupling or cohesion
Inappropriate Intimacy, Feature Envy, Data Clumps, …
Too much or too little delegation
Message Chains, Middle Man, …
Non Object-Oriented control or data structures
Switch Statements, Primitive Obsession, …
Other : Comments, …
68
Some more bad smells
Temporary Field
Divergent Change
Speculative Generality
Alternative Classes with Different Interfaces
Incomplete Library
Refused Bequest
Comments
69
Temporary Field
Instance variables that are only set sometimes are
hard to understand; you expect an object to need
all its variables.
Use Extract Class to put the orphan variable
and all the code that concerns it in one place.
Use Introduce Null Object when the variable is
just around to deal with the null special case.
70
Divergent Change
When one class is commonly changed

in different ways for different reasons.
When we make a change we want to be able to jump
to a single clear point in the system and make the
change. If you can’t do this you’ve got a bad smell.
To clean this up you identify everything that changes
for a particular cause and use Extract Class to put
them all together.
71* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Speculative Generality
When someone says “I think

we may need the ability to do

this someday ”
At this time you need all sorts of hooks and special
cases to handle things that are not required
Use Collapse Hierarchy – Inline Class –
Remove Parameter – Rename Method
72* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Alternative Classes with Different Interfaces
Methods in different classes

that do the same thing but

have different signatures.
Use Rename Method
Keep using Move Method to move behaviour
until protocols are the same
73* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Incomplete Library Class
When a library or framework class doesn't provide all the
functionality you need
But the solution to the problem, changing the library, is
impossible since it is read-only.
Use Introduce Foreign Method and Introduce Local
Extension
See details of these refactorings for more information on how they
solve the problem
74
Refused Bequest
When a subclass ignores

and doesn’t need most of

the functionality provided

by its superclass
Can give confusion and problems
You need to create a new sibling class and use Push
Down Method and Push Down Field to push all
the unused methods to the sibling.
75* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Comments
Are comments bad?
Of course not! In general comments are a good thing to have.
But… sometimes comments are just an excuse for bad
code
It stinks when you have a big comment which tries to explain
bad code
such comments are used as a deodorant to hide the rotten
code underneath
76* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only.
*
Comments: Example
while (i<NRULES) {
while (j<COL-1 && !(grammar[i][j+1].equals("N"))) {
init(first);
if (matrix[k][l] != 'R') {
if (cs.indexOf(q)!=-1) {
init(second);
for (int p=0;p < stIndex.size();indexHeadGram++){
…
« Look which rule to choose, and after we know which
rule to take we initialize the array matrix with the correct
value (depending on the rule). We do that until we have
tested all rules and after that we … blablabla »
77
Comments: Refactoring Patterns
Using refactorings, our first action is to remove the bad
smells in the commented code
After having done this, we often find that the comments
have become superfluous
To avoid bad smells we can often use Extract Method
Usually the name of the new method is enough then to
explain what the code does
78
Comments: Example
public double price() {
//price is base price – quantity discount + shipping
return quantity * itemPrice –
Math.max(0, quantity – 500) * itemPrice * 0.05 +
Math.min(quantity * itemPrice * 0.1, 100.0) }
public double price() {return basePrice – quantityDiscount + shipping }
private double basePrice() {return quantity *itemPrice }
private double quantityDiscount () {return Math.max(0, quantity – 500) * itemPrice * 0.05 }
private double shipping () {Math.min(quantity * itemPrice * 0.1, 100.0) }
Extract method
79
Comments: Refactoring Patterns
Sometimes the method is already extracted but
still needs a comment to explain what it does
One solution could be : Rename Method
80
Comments: Example
public double price() {return basePrice – Price2 + shipping }
private double basePrice() {return quantity *itemPrice }
private double Price2 () {return Math.max(0, quantity – 500) * itemPrice * 0.05 }
private double shipping () {Math.min(quantity * itemPrice * 0.1, 100.0) }
// Price2 represent the quantityDiscount
81
public double price() {return basePrice – quantityDiscount + shipping }
private double basePrice() {return quantity *itemPrice }
private double quantityDiscount () {return Math.max(0, quantity – 500) * itemPrice * 0.05 }
private double shipping () {Math.min(quantity * itemPrice * 0.1, 100.0) }
Rename method
Comments: Refactoring Patterns
A section of code assumes something about the
state of the program.
A comment is required to state the rule.
To avoid it, we can use Introduce Assertion
82
Comments: Example
Public double getExpenseLimit() {
// should have either expense limit or a primary project
return (_expenseLimit != NULL_EXPENSE) ?
_expenseLimit:
_primaryProject.getMemberExpenseLimit(); }
Public double getExpenseLimit() {
assert.isTrue (_expenseLimit != NULL_EXPENSE || _primaryProject != null);
return (_expenseLimit != NULL_EXPENSE) ?
_expenseLimit:
_primaryProject.getMemberExpenseLimit(); }
Introduce Assertion
83
Comments: Refactoring patterns
(Summary)
Bad
comments
Extract Method
Rename Method
Introduce Assertion
No more bad
comments
84
Comments: some last remarks…
When is a comment needed / useful ?
Tip : Whenever you feel the need to write a comment, first try to
refactor the code so that any comment becomes superfluous
A good time to use a comment is when you don’t know exactly what to do
A comment is a good place to say why you did something.
This kind of information helps future modifiers, especially forgetful
ones, including yourself
A last case is to use comments when something has not been done during
development
85
C. CONCLUSION
LINGI2252 – PROF. KIM MENS
Problems with bad smells
Only a good recipe book and nothing more
It isn't always easy or even useful to use
Sometimes depends on context

and personal style / taste
Most of them are specific to OO
87
Conclusion
To have a good habitable code:
How? Refactorings
When? Bad Smells
Bad smells are only a recipe book to help us find
the right refactoring patterns to apply
88
Bad Code Smells
BAD CODE SMELLS
POSSIBLE QUESTIONS (1)
▸ Which bad smell could be corrected by applying the “Introduce Parameter Object”
refactoring?
▸ Which refactorings would you probably apply to address the “Large Class” bad smell?
▸ Explain and illustrate one of the following bad smells: Long Method, Feature Envy or Middle
Man.
▸ Explain the Long Parameter List bad smell in detail. Why is it a bad smell? How could it be
solved with a refactoring?
▸ What’s the relation between the Long Parameter List bad smell and the Data Clumps bad
smell?
BAD CODE SMELLS
POSSIBLE QUESTIONS (2)
▸ Explain and illustrate what the notion of “coupling” is. Should we strive for loose coupling or
tight coupling? What bad smell describes a situation that violates this principle? Name and
explain at least one.
▸ Explain and illustrate what the notion of “cohesion” is. Should we strive for low cohesion or high
cohesion? What bad smell describes a situation that violates this principle? Name and explain at
least one.
▸ Some bad smells are based on the principle that “things that change together should go
together”. Explain one of these bad smells, and the principle on which they are based, in detail.
▸ Name and explain at least one bad smell that explains a problem related to bad use of
inheritance.
▸ When talking about “Comments” in the bad smells theory session, it was stated that comments
are sometimes just there because the code is bad. Can you give an example of this and how
such comments could become superfluous simply by refactoring the code?

Mais conteúdo relacionado

Mais procurados (20)

Clean code
Clean codeClean code
Clean code
 
Introduction to SOLID Principles
Introduction to SOLID PrinciplesIntroduction to SOLID Principles
Introduction to SOLID Principles
 
Refactoring
RefactoringRefactoring
Refactoring
 
Code smells and remedies
Code smells and remediesCode smells and remedies
Code smells and remedies
 
Clean Code na Prática
Clean Code na PráticaClean Code na Prática
Clean Code na Prática
 
SOLID Design Principles
SOLID Design PrinciplesSOLID Design Principles
SOLID Design Principles
 
Clean code
Clean codeClean code
Clean code
 
Refactoring: Improve the design of existing code
Refactoring: Improve the design of existing codeRefactoring: Improve the design of existing code
Refactoring: Improve the design of existing code
 
SOLID Design Principles applied in Java
SOLID Design Principles applied in JavaSOLID Design Principles applied in Java
SOLID Design Principles applied in Java
 
Clean code
Clean codeClean code
Clean code
 
Code refactoring
Code refactoringCode refactoring
Code refactoring
 
Clean code slide
Clean code slideClean code slide
Clean code slide
 
Clean code
Clean codeClean code
Clean code
 
Solid Principles
Solid PrinciplesSolid Principles
Solid Principles
 
Solid principles
Solid principlesSolid principles
Solid principles
 
Clean coding-practices
Clean coding-practicesClean coding-practices
Clean coding-practices
 
Refactoring
RefactoringRefactoring
Refactoring
 
Refactoring
RefactoringRefactoring
Refactoring
 
Design principle vs design patterns
Design principle vs design patternsDesign principle vs design patterns
Design principle vs design patterns
 
Software Craftsmanship - Code Smells - Change Preventers
Software Craftsmanship - Code Smells - Change PreventersSoftware Craftsmanship - Code Smells - Change Preventers
Software Craftsmanship - Code Smells - Change Preventers
 

Destaque

Breaking the Walls: A Unified Vision on Context-Oriented Software Engineering
Breaking the Walls: A Unified Vision on Context-Oriented Software EngineeringBreaking the Walls: A Unified Vision on Context-Oriented Software Engineering
Breaking the Walls: A Unified Vision on Context-Oriented Software Engineeringkim.mens
 
A Catalogue of Code Smell Visualizations
A Catalogue of Code Smell VisualizationsA Catalogue of Code Smell Visualizations
A Catalogue of Code Smell VisualizationsChris Parnin
 
When and Why Your Code Starts to Smell Bad
When and Why Your Code Starts to Smell BadWhen and Why Your Code Starts to Smell Bad
When and Why Your Code Starts to Smell BadCarlos Eduardo
 
Do Code Smell Hamper Novice Programmers?
Do Code Smell Hamper Novice Programmers?Do Code Smell Hamper Novice Programmers?
Do Code Smell Hamper Novice Programmers?Felienne Hermans
 
Code Smell Research: History and Future Directions
Code Smell Research: History and Future DirectionsCode Smell Research: History and Future Directions
Code Smell Research: History and Future DirectionsNikolaos Tsantalis
 
A Textual-based Technique for Smell Detection
A Textual-based Technique for Smell DetectionA Textual-based Technique for Smell Detection
A Textual-based Technique for Smell DetectionFabio Palomba
 
Detecting Bad Smells in Source Code using Change History Information
Detecting Bad Smells in Source Code using Change History InformationDetecting Bad Smells in Source Code using Change History Information
Detecting Bad Smells in Source Code using Change History InformationFabio Palomba
 
Does your configuration code smell?
Does your configuration code smell?Does your configuration code smell?
Does your configuration code smell?Tushar Sharma
 
Ruby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorb
Ruby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorbRuby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorb
Ruby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorbKoichiro Sumi
 

Destaque (11)

Breaking the Walls: A Unified Vision on Context-Oriented Software Engineering
Breaking the Walls: A Unified Vision on Context-Oriented Software EngineeringBreaking the Walls: A Unified Vision on Context-Oriented Software Engineering
Breaking the Walls: A Unified Vision on Context-Oriented Software Engineering
 
A Catalogue of Code Smell Visualizations
A Catalogue of Code Smell VisualizationsA Catalogue of Code Smell Visualizations
A Catalogue of Code Smell Visualizations
 
When and Why Your Code Starts to Smell Bad
When and Why Your Code Starts to Smell BadWhen and Why Your Code Starts to Smell Bad
When and Why Your Code Starts to Smell Bad
 
Do Code Smell Hamper Novice Programmers?
Do Code Smell Hamper Novice Programmers?Do Code Smell Hamper Novice Programmers?
Do Code Smell Hamper Novice Programmers?
 
Code Smell Research: History and Future Directions
Code Smell Research: History and Future DirectionsCode Smell Research: History and Future Directions
Code Smell Research: History and Future Directions
 
A Textual-based Technique for Smell Detection
A Textual-based Technique for Smell DetectionA Textual-based Technique for Smell Detection
A Textual-based Technique for Smell Detection
 
PhD Symposium 2014
PhD Symposium 2014PhD Symposium 2014
PhD Symposium 2014
 
Detecting Bad Smells in Source Code using Change History Information
Detecting Bad Smells in Source Code using Change History InformationDetecting Bad Smells in Source Code using Change History Information
Detecting Bad Smells in Source Code using Change History Information
 
Does your configuration code smell?
Does your configuration code smell?Does your configuration code smell?
Does your configuration code smell?
 
Code smells
Code smellsCode smells
Code smells
 
Ruby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorb
Ruby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorbRuby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorb
Ruby用の静的コード解析ツールざくっと紹介 by SideCI #omotesandorb
 

Semelhante a Bad Code Smells

Bade Smells in Code
Bade Smells in CodeBade Smells in Code
Bade Smells in CodeWill Shen
 
Agile korea 2013 유석문
Agile korea 2013 유석문Agile korea 2013 유석문
Agile korea 2013 유석문Sangcheol Hwang
 
Code smells quality of code
Code smells   quality of codeCode smells   quality of code
Code smells quality of codeHasan Al Mamun
 
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...Justin Gordon
 
[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...
[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...
[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...DevDay.org
 
Software Craftsmanship - 2
Software Craftsmanship - 2Software Craftsmanship - 2
Software Craftsmanship - 2Uri Lavi
 
Refactoring Tips by Martin Fowler
Refactoring Tips by Martin FowlerRefactoring Tips by Martin Fowler
Refactoring Tips by Martin FowlerIgor Crvenov
 
C# coding standards, good programming principles & refactoring
C# coding standards, good programming principles & refactoringC# coding standards, good programming principles & refactoring
C# coding standards, good programming principles & refactoringEyob Lube
 
Java method present by showrov ahamed
Java method present by showrov ahamedJava method present by showrov ahamed
Java method present by showrov ahamedMd Showrov Ahmed
 
Implementation
ImplementationImplementation
Implementationadil raja
 
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...ijcnes
 
C#3.0 & Vb 9.0 New Features
C#3.0 & Vb 9.0 New FeaturesC#3.0 & Vb 9.0 New Features
C#3.0 & Vb 9.0 New Featurestechfreak
 

Semelhante a Bad Code Smells (20)

Bade Smells in Code
Bade Smells in CodeBade Smells in Code
Bade Smells in Code
 
Refactoring
RefactoringRefactoring
Refactoring
 
Agile korea 2013 유석문
Agile korea 2013 유석문Agile korea 2013 유석문
Agile korea 2013 유석문
 
Code smells quality of code
Code smells   quality of codeCode smells   quality of code
Code smells quality of code
 
Code Refactoring
Code RefactoringCode Refactoring
Code Refactoring
 
Clean Code V2
Clean Code V2Clean Code V2
Clean Code V2
 
Code Metrics
Code MetricsCode Metrics
Code Metrics
 
C# interview questions
C# interview questionsC# interview questions
C# interview questions
 
Refactoring
RefactoringRefactoring
Refactoring
 
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
 
[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...
[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...
[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...
 
Software Craftsmanship - 2
Software Craftsmanship - 2Software Craftsmanship - 2
Software Craftsmanship - 2
 
Refactoring Tips by Martin Fowler
Refactoring Tips by Martin FowlerRefactoring Tips by Martin Fowler
Refactoring Tips by Martin Fowler
 
C# coding standards, good programming principles & refactoring
C# coding standards, good programming principles & refactoringC# coding standards, good programming principles & refactoring
C# coding standards, good programming principles & refactoring
 
Java method present by showrov ahamed
Java method present by showrov ahamedJava method present by showrov ahamed
Java method present by showrov ahamed
 
Implementation
ImplementationImplementation
Implementation
 
7494605
74946057494605
7494605
 
OOPSCA1.pptx
OOPSCA1.pptxOOPSCA1.pptx
OOPSCA1.pptx
 
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...
 
C#3.0 & Vb 9.0 New Features
C#3.0 & Vb 9.0 New FeaturesC#3.0 & Vb 9.0 New Features
C#3.0 & Vb 9.0 New Features
 

Mais de kim.mens

Software Maintenance and Evolution
Software Maintenance and EvolutionSoftware Maintenance and Evolution
Software Maintenance and Evolutionkim.mens
 
Context-Oriented Programming
Context-Oriented ProgrammingContext-Oriented Programming
Context-Oriented Programmingkim.mens
 
Software Reuse and Object-Oriented Programming
Software Reuse and Object-Oriented ProgrammingSoftware Reuse and Object-Oriented Programming
Software Reuse and Object-Oriented Programmingkim.mens
 
Object-Oriented Design Heuristics
Object-Oriented Design HeuristicsObject-Oriented Design Heuristics
Object-Oriented Design Heuristicskim.mens
 
Software Patterns
Software PatternsSoftware Patterns
Software Patternskim.mens
 
Domain Modelling
Domain ModellingDomain Modelling
Domain Modellingkim.mens
 
Object-Oriented Application Frameworks
Object-Oriented Application FrameworksObject-Oriented Application Frameworks
Object-Oriented Application Frameworkskim.mens
 
Towards a Context-Oriented Software Implementation Framework
Towards a Context-Oriented Software Implementation FrameworkTowards a Context-Oriented Software Implementation Framework
Towards a Context-Oriented Software Implementation Frameworkkim.mens
 
Towards a Taxonomy of Context-Aware Software Variabilty Approaches
Towards a Taxonomy of Context-Aware Software Variabilty ApproachesTowards a Taxonomy of Context-Aware Software Variabilty Approaches
Towards a Taxonomy of Context-Aware Software Variabilty Approacheskim.mens
 
Context-oriented programming
Context-oriented programmingContext-oriented programming
Context-oriented programmingkim.mens
 
Basics of reflection
Basics of reflectionBasics of reflection
Basics of reflectionkim.mens
 
Advanced Reflection in Java
Advanced Reflection in JavaAdvanced Reflection in Java
Advanced Reflection in Javakim.mens
 
Basics of reflection in java
Basics of reflection in javaBasics of reflection in java
Basics of reflection in javakim.mens
 
Reflection in Ruby
Reflection in RubyReflection in Ruby
Reflection in Rubykim.mens
 
Introduction to Ruby
Introduction to RubyIntroduction to Ruby
Introduction to Rubykim.mens
 
Introduction to Smalltalk
Introduction to SmalltalkIntroduction to Smalltalk
Introduction to Smalltalkkim.mens
 
A gentle introduction to reflection
A gentle introduction to reflectionA gentle introduction to reflection
A gentle introduction to reflectionkim.mens
 
Managing the Evolution of Information Systems with Intensional Views and Rela...
Managing the Evolution of Information Systems with Intensional Views and Rela...Managing the Evolution of Information Systems with Intensional Views and Rela...
Managing the Evolution of Information Systems with Intensional Views and Rela...kim.mens
 
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)kim.mens
 
Usage contracts in a nutshell
Usage contracts in a nutshellUsage contracts in a nutshell
Usage contracts in a nutshellkim.mens
 

Mais de kim.mens (20)

Software Maintenance and Evolution
Software Maintenance and EvolutionSoftware Maintenance and Evolution
Software Maintenance and Evolution
 
Context-Oriented Programming
Context-Oriented ProgrammingContext-Oriented Programming
Context-Oriented Programming
 
Software Reuse and Object-Oriented Programming
Software Reuse and Object-Oriented ProgrammingSoftware Reuse and Object-Oriented Programming
Software Reuse and Object-Oriented Programming
 
Object-Oriented Design Heuristics
Object-Oriented Design HeuristicsObject-Oriented Design Heuristics
Object-Oriented Design Heuristics
 
Software Patterns
Software PatternsSoftware Patterns
Software Patterns
 
Domain Modelling
Domain ModellingDomain Modelling
Domain Modelling
 
Object-Oriented Application Frameworks
Object-Oriented Application FrameworksObject-Oriented Application Frameworks
Object-Oriented Application Frameworks
 
Towards a Context-Oriented Software Implementation Framework
Towards a Context-Oriented Software Implementation FrameworkTowards a Context-Oriented Software Implementation Framework
Towards a Context-Oriented Software Implementation Framework
 
Towards a Taxonomy of Context-Aware Software Variabilty Approaches
Towards a Taxonomy of Context-Aware Software Variabilty ApproachesTowards a Taxonomy of Context-Aware Software Variabilty Approaches
Towards a Taxonomy of Context-Aware Software Variabilty Approaches
 
Context-oriented programming
Context-oriented programmingContext-oriented programming
Context-oriented programming
 
Basics of reflection
Basics of reflectionBasics of reflection
Basics of reflection
 
Advanced Reflection in Java
Advanced Reflection in JavaAdvanced Reflection in Java
Advanced Reflection in Java
 
Basics of reflection in java
Basics of reflection in javaBasics of reflection in java
Basics of reflection in java
 
Reflection in Ruby
Reflection in RubyReflection in Ruby
Reflection in Ruby
 
Introduction to Ruby
Introduction to RubyIntroduction to Ruby
Introduction to Ruby
 
Introduction to Smalltalk
Introduction to SmalltalkIntroduction to Smalltalk
Introduction to Smalltalk
 
A gentle introduction to reflection
A gentle introduction to reflectionA gentle introduction to reflection
A gentle introduction to reflection
 
Managing the Evolution of Information Systems with Intensional Views and Rela...
Managing the Evolution of Information Systems with Intensional Views and Rela...Managing the Evolution of Information Systems with Intensional Views and Rela...
Managing the Evolution of Information Systems with Intensional Views and Rela...
 
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
Usage contracts (presented at SATToSE 2014 in L'Aquila, Italy)
 
Usage contracts in a nutshell
Usage contracts in a nutshellUsage contracts in a nutshell
Usage contracts in a nutshell
 

Último

How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17Celine George
 
What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?TechSoup
 
A gentle introduction to Artificial Intelligence
A gentle introduction to Artificial IntelligenceA gentle introduction to Artificial Intelligence
A gentle introduction to Artificial IntelligenceApostolos Syropoulos
 
Riddhi Kevadiya. WILLIAM SHAKESPEARE....
Riddhi Kevadiya. WILLIAM SHAKESPEARE....Riddhi Kevadiya. WILLIAM SHAKESPEARE....
Riddhi Kevadiya. WILLIAM SHAKESPEARE....Riddhi Kevadiya
 
Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.raviapr7
 
How to Send Emails From Odoo 17 Using Code
How to Send Emails From Odoo 17 Using CodeHow to Send Emails From Odoo 17 Using Code
How to Send Emails From Odoo 17 Using CodeCeline George
 
The basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxThe basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxheathfieldcps1
 
HED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdfHED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdfMohonDas
 
3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptx3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptxmary850239
 
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRADUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRATanmoy Mishra
 
AUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptxAUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptxiammrhaywood
 
CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...
CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...
CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...Nguyen Thanh Tu Collection
 
How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17Celine George
 
How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17Celine George
 
Work Experience for psp3 portfolio sasha
Work Experience for psp3 portfolio sashaWork Experience for psp3 portfolio sasha
Work Experience for psp3 portfolio sashasashalaycock03
 
In - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptxIn - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptxAditiChauhan701637
 
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptxClinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptxraviapr7
 

Último (20)

How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17How to Show Error_Warning Messages in Odoo 17
How to Show Error_Warning Messages in Odoo 17
 
What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?
 
A gentle introduction to Artificial Intelligence
A gentle introduction to Artificial IntelligenceA gentle introduction to Artificial Intelligence
A gentle introduction to Artificial Intelligence
 
Riddhi Kevadiya. WILLIAM SHAKESPEARE....
Riddhi Kevadiya. WILLIAM SHAKESPEARE....Riddhi Kevadiya. WILLIAM SHAKESPEARE....
Riddhi Kevadiya. WILLIAM SHAKESPEARE....
 
Finals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quizFinals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quiz
 
Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.Drug Information Services- DIC and Sources.
Drug Information Services- DIC and Sources.
 
How to Send Emails From Odoo 17 Using Code
How to Send Emails From Odoo 17 Using CodeHow to Send Emails From Odoo 17 Using Code
How to Send Emails From Odoo 17 Using Code
 
The basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptxThe basics of sentences session 10pptx.pptx
The basics of sentences session 10pptx.pptx
 
Personal Resilience in Project Management 2 - TV Edit 1a.pdf
Personal Resilience in Project Management 2 - TV Edit 1a.pdfPersonal Resilience in Project Management 2 - TV Edit 1a.pdf
Personal Resilience in Project Management 2 - TV Edit 1a.pdf
 
HED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdfHED Office Sohayok Exam Question Solution 2023.pdf
HED Office Sohayok Exam Question Solution 2023.pdf
 
3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptx3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptx
 
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRADUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
DUST OF SNOW_BY ROBERT FROST_EDITED BY_ TANMOY MISHRA
 
AUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptxAUDIENCE THEORY -- FANDOM -- JENKINS.pptx
AUDIENCE THEORY -- FANDOM -- JENKINS.pptx
 
CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...
CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...
CHUYÊN ĐỀ DẠY THÊM TIẾNG ANH LỚP 11 - GLOBAL SUCCESS - NĂM HỌC 2023-2024 - HK...
 
Prelims of Kant get Marx 2.0: a general politics quiz
Prelims of Kant get Marx 2.0: a general politics quizPrelims of Kant get Marx 2.0: a general politics quiz
Prelims of Kant get Marx 2.0: a general politics quiz
 
How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17
 
How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17
 
Work Experience for psp3 portfolio sasha
Work Experience for psp3 portfolio sashaWork Experience for psp3 portfolio sasha
Work Experience for psp3 portfolio sasha
 
In - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptxIn - Vivo and In - Vitro Correlation.pptx
In - Vivo and In - Vitro Correlation.pptx
 
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptxClinical Pharmacy  Introduction to Clinical Pharmacy, Concept of clinical pptx
Clinical Pharmacy Introduction to Clinical Pharmacy, Concept of clinical pptx
 

Bad Code Smells

  • 1. BAD CODE SMELLS LINGI2252 – PROF. KIM MENS * These slides are part of the course LINGI2252 “Software Maintenance and Evolution”, given by Prof. Kim Mens at UCL, Belgium *
  • 3. Bad Smells in Code Reference Martin Fowler, Refactoring: Improving the Design of Existing Code.
 Addison Wesley, 2000. ISBN: 0201485672 Chapter 3: Bad Smells in Code, by Kent Beck and Martin Fowler Overview of this presentation Introduction A classification of bad smells, including a 
 detailed illustration of some of them Conclusion 3
  • 4. Introduction Bad Smells = “bad smelling code” indicate that your code is ripe for refactoring Refactoring is about how to change code by applying refactorings Bad smells are about when to modify it 4
  • 5. Bad Smells Allow us to identify what needs to be changed in order to improve the code A recipe book to help us choose the right refactoring pattern No precise criteria More to give an intuition and indications Goal : a more “habitable” code. 5
  • 6. Side note: Habitable code Habitable code is code in which developers feel at home
 (even when the code was not written by them) Symptoms of inhabitable code include
 overuse of abstraction or inappropriate compression Habitable code should be easy to read, easy to change Software needs to be habitable because it always has to change [Richard P. Gabriel, Patterns of Software: Tales from the
 Software Community, Oxford University Press, 1996] 6
  • 7. B. CLASSIFICATION OF BAD SMELLS
 INCLUDING A DETAILED DISCUSSION OF 5 OF THEM LINGI2252 – PROF. KIM MENS
  • 8. An Online Classification https://sourcemaking.com/refactoring 8 DISCLAIMER:
 SEVERAL CARTOONS SHOWN IN THIS PRESENTATION WERE BORROWED FROM THAT SITE
  • 9. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments 9
  • 10. Bad Smells : Alternative Classification Bloaters are too large to handle Object-orientation abusers
 do not respect OO principles Change preventers stand in the way of change Dispensables are things you could do without Couplers contribute to excessive coupling between classes Other smells 10
  • 11. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments 11
  • 12. The top crime 12 Code duplication
  • 13. Code duplication Duplicated code is the number 1 in the stink parade ! We have duplicated code when we have
 the same code structure in more than one place Why is duplicated code bad? A fundamental rule of thumb :
 it’s always better to have a unified code 13
  • 14. 14 Code duplication example 1 public double ringSurface(r1,r2) { // calculate the surface of the first circle double surf1 = bigCircleSurface(r1); // calculate the surface of the second circle double surf2 = smallCircleSurface(r2); return surf1 - surf2; } private double bigCircleSurface(r1) { pi = 4* ( arctan 1/2 + arctan 1/3 ); return pi*sqr(r1); } private double smallCircleSurface(r2) { pi = 4* ( arctan 1/2 + arctan 1/3 ); return pi*sqr(r2); }
  • 15. 15 Code duplication example 2 Class method1 method2 method3 code code code code Same expression in two or more methods of the same class
  • 16. 16 Code duplication example 3 methodA code Class methodB code SubClassA SubClassB Same expression in two sibling classes inherits from
  • 17. 17 Code duplication example 4 methodA code methodB code ClassA ClassB Same expression in two unrelated classes
  • 18. 18 Code duplication: Refactoring Patterns (1) public double ringSurface(r1,r2) { // calculate the surface of the first circle double surf1 = surface(r1); //calculate the surface of the second circle double surf2 = surface(r2); return surf1-surf2; } private double surface(r) { pi = 4* ( arctan 1/2 + arctan 1/3 ); return pi*sqr(r); } Extract method + Rename method
  • 19. 19 Code duplication: Refactoring Patterns (2) Class method1 method2 method3 code code code code Same expression in two or more methods of the same class Extract method Class method1 method2 Call methX() Call methX() Call methX() method3 Call methX() methX() xcodeReturn
  • 20. 20 Code duplication: Refactoring Patterns (3) Same expression in two sibling classes Extract method + Pull up field Same code Extract method + Form Template Method Similar code Substitute algorithm Different algorithm Class SubClass A SubClass B
  • 21. 21 Code duplication: Refactoring Patterns (4) methodA ClassA ClassB Same expression in two unrelated classes Call ClassC.methX() methodB Call ClassC.methX() methX() codereturn Extract class Extract class code code
  • 22. 22 Code duplication: Refactoring Patterns (4’) methodA ClassA ClassB Same expression in two unrelated classes Call ClassC.methXcode() methodB Call ClassA.methodA() If the method really belongs in one of the two classes, keep it there and invoke it from the other class code code
  • 23. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments 23
  • 24. Large Class A large class is a class that
 is trying to do too much Often shows up as too many instance variables Use Extract Class or Extract Subclass to bundle variables choose variables that belong together in the extracted class common prefixes and suffixes may suggest which ones may go together, e.g. depositAmount and depositCurrency 24* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 25. Large Class A class may also be too large in the sense that it has too much code likely some code inside the class is duplicated solve it by extracting the duplicated code in separate methods using Extract Method or move part of the code to a new class, using Extract Class or Extract Subclass if need be, move existing or extracted methods to another class using Move Method 25
  • 26. Long Parameter List In procedural programming languages, we pass as parameters everything needed by a subroutine Because the only alternative is global variables With objects you don’t pass everything the method needs 26* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 27. Long Parameter List Long parameter lists are hard to understand Pass only the needed number of variables Use Replace Parameter with Method when you can get the data in one parameter by making a request of an object you already know about 27
  • 28. Lazy Class Each class cost money (and brain cells) to maintain and understand A class that isn't doing enough to pay for itself should be eliminated It might be a class that was added because of changes that were planned but not made Use Collapse Hierarchy or Inline Class to eliminate the class. Person name getTelephoneNumber Telephone Number areaCode
 number getTelephoneNumber Person name
 areaCode
 number getTelephoneNumber 28* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 29. Data Class Classes with just fields, getters, setters and nothing else If there are public fields, use Encapsulate Field For fields that should not be changed use Remove Setting Method 29* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 30. Long Method Object programs live best and longest with short methods New OO programmers feel that OO programs are endless sequences of delegation Older languages carried an overhead in subroutine calls which deterred people from small methods There is still an overhead to the reader of the code because you have to switch context to see what the subprocedure does (but the development environment helps us) Important to have a good name for small methods Rename Method 30
  • 31. Long Method The longer a procedure is, the more difficult it is to understand what the code does More difficult to read Bad for maintainability More difficult to make modifications To summarise… less habitable ! 31* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 32. Long Method Too avoid too long methods, decompose methods in many small ones Heuristic: whenever you feel the need to comment something, write a method instead containing the code that was commented named it after the intention of the code
 rather than how it does it Even a single line is worth extracting if it needs explanation 32
  • 33. Long Method: Example 33 void printOwing() { Enumeration e = _orders.elements(); double outstanding = 0.0; // Print banner
 System.out.println(“******************“);
 System.out.println(“***** Customer *****“);
 System.out.println(“******************“); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } // Print details
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 } Example was shortened to fit on 1 slide
  • 34. Long Method: Refactoring patterns 99% of the time, all we have to do to shorten a method is Extract Method Find parts of the method that seem to go together nicely and extract them into a new method. It can lead to problems… Many temps : use Replace Temp with Query Long lists of parameters can be slimmed down with Introduce Parameter Object 34
  • 35. Long Method: Refactoring patterns But how to identify the clumps of code to extract ? Look for comments… A block of code with a comment that tells you what it is doing can be replaced by a method whose name is based on the comments Loops also give signs for extractions… Extract the loop and the code within the loop into its own method. 35
  • 36. Long Method Example revisited 36 void printOwing() { Enumeration e = _orders.elements(); double outstanding = 0.0; // Print banner
 System.out.println(“******************“);
 System.out.println(“***** Customer *****“);
 System.out.println(“******************“); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } // Print details
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 }
  • 37. Long Method Example revisited 37 void printOwing() { Enumeration e = _orders.elements(); double outstanding = 0.0; // Print banner
 System.out.println(“******************“);
 System.out.println(“***** Customer *****“);
 System.out.println(“******************“); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } // Print details
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 }
  • 38. Long Method Example revisited 38 void printOwing() { Enumeration e = _orders.elements();
 double outstanding = 0.0; printBanner(); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } // Print details
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 } void printBanner() {
 System.out.println(“******************“);
 System.out.println(“***** Customer ****“);
 System.out.println(“******************“);
 } 1.
 Extract Method
 Trivially easy !
  • 39. Long Method Example revisited 39 void printOwing() { Enumeration e = _orders.elements();
 double outstanding = 0.0; printBanner(); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } // Print details
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 } void printBanner() {
 System.out.println(“******************“);
 System.out.println(“***** Customer ****“);
 System.out.println(“******************“);
 }
  • 40. Long Method Example revisited 40 2.
 Extract Method
 Using Local Variables void printOwing() { Enumeration e = _orders.elements();
 double outstanding = 0.0; printBanner(); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } printDetails(outstanding);
 } void printDetails(double outstanding) { 
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 } void printBanner() { … }
  • 41. Long Method Example revisited 41 void printOwing() { Enumeration e = _orders.elements();
 double outstanding = 0.0; printBanner(); // Calcultate outstanding
 While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 outstanding += each.getAmount();
 } printDetails(outstanding);
 } void printDetails(double outstanding) { 
 System.out.println(“name: “ + _name);
 System.out.println(“amount” + outstanding);
 } void printBanner() { … }
  • 42. Long Method Example revisited 42 3.
 Extract Method Reassigning a Local Variable void printOwing() { printBanner(); double outstanding = getOutstanding(); printDetails(outstanding);
 } double getOutstanding() { Enumeration e = _orders.elements();
 double result = 0.0; While (e.hasMoreElements()) {
 Order each = (Order) e.nextElement();
 result += each.getAmount();
 }
 return result;
 } void printDetails(double outstanding) {…} void printBanner() { … }
  • 43. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments 43
  • 44. Coupling and cohesion Coupling is the degree to which different software components depend on each other Cohesion is the degree to which the elements within a software module belong together Low cohesion and tight coupling are bad smells (why?) 44
  • 45. Inappropriate Intimacy Pairs of classes that know too much about each other's private details Use Move Method and Move Field to separate the pieces to reduce the intimacy If subclasses know more about their parents than their parents would like them to know Apply Replace Inheritance with Delegation 45* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 46. Data Clumps A certain number of data items in lots of places Examples: fields in a couple of classes, parameters in many method signatures Ought to be made into their own object When the clumps are fields, use Extract Class to turn them into an object When the clumps are parameters, use Introduce Parameter Object to slim them down 46
  • 47. Feature Envy When a method seems more interested in a class other than the one it actually is in 47* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 48. Feature Envy In other words, When a method invokes too many times methods on another object to calculate some value Why is it bad to invoke a zillion times methods from another class? Because, in general, it is not logical from an OO point of view. Put things together that change together ! 48
  • 49. Feature Envy: Example (1) public Void mainFeatureEnvy () { OtherClass.getMethod1(); OtherClass.getMethod2(); OtherClass.getMethod3(); OtherClass.getMethod4(); } public Void getMethod1 () { … } public Void getMethod2 () { … } public Void getMethod3 () { … } public Void getMethod4 () { … } OtherClass 49
  • 50. Feature Envy: Refactoring Patterns (1) First solution : Move Method Public Void getMethod1 () { … } Public Void getMethod2 () { … } Public Void getMethod3 () { … } Public Void getMethod4 () { … } Public Void mainFeatureEnvy () { getMethod1(); getMethod2(); getMethod3(); getMethod4(); } OtherClass Could we use Extract method ? Yes ! If only a part of the method suffers from envy 50
  • 51. Feature Envy: Example (2) Public Void mainFeatureEnvy () { Class1.getMethod1(); Class1.getMethod2(); Class2.getMethod3(); Class2.getMethod4(); } Public Void getMethod1 () { … } Public Void getMethod2 () { … } Class1 Public Void getMethod3 () { … } Public Void getMethod4 () { … } Class2 ? 51
  • 52. Feature Envy: Refactoring Patterns (2) Use the same method as the first example : Extract Method or Move Method To choose the good class we use the following heuristic : determine which class has most of the data and put the method with that data 52
  • 53. Shotgun Surgery When making one kind of change requires many small changes to a lot of different classes 53* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 54. Shotgun Surgery Hard to find all changes needed; easy to miss an important change Use Move Method and Move Field to put all change sites into one class Put things together that change together ! If a good place to put them does not exist, create one. 54
  • 55. Parallel Inheritance Hierarchies Special case of Shotgun Surgery Each time I add a subclass to one hierarchy, I need to do it for all related hierarchies Use Move Method
 and Move Field 55* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 56. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments 56
  • 57. Message Chains A client asks an object for another object who then asks that object for another object, etc. Bad because client depends on the structure of the navigation Use Extract Method and Move Method to break up or shorten such chains 57* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 58. Middle Man Objects hide internal details (encapsulation) Encapsulation leads to delegation It is a good concept but... Sometimes it goes to far… 58
  • 59. Middle Man Real-life example: You ask a director whether she is free for a meeting She delegates the message to her secretary that delegates it to the diary. Everything is good… but, if the secretary has nothing else to do, it is better to remove her ! 59
  • 60. Middle Man If a class performs only one action, delegating work to other classes, why does it exist at all? Sometimes most methods of class just delegate to another class 60* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 61. Middle Man: Example 61 class Person
 Department _department;
 public Person getManager() {
 return _department.getManager();
 } class Department
 private Person _manager;
 public Department (Person manager) {
 _manager = manager; }
 public Person getManager() {
 return _manager(); }
 } The class Person is hiding the Department class. To find a person’s manager, clients ask :
 Manager = john.getManager(); and the person then needs to ask :
 _department.getManager(); client class Person getManager() Department getManager()
  • 62. 62 Middle Man: Refactoring Remove Middle Man client class Person getDepartment() Department getManager() client class Person getManager() Department getManager()
  • 63. 63 Middle Man: Refactoring Remove Middle Man… First step : Create an accessor for the delegate. class Person {
 Department _department;
 public Person getManager() {
 return _department.getManager(); }
 public Department getDepartment() {
 return _department; }
 } client class Person getManager() getDepartment() Department getManager()
  • 64. 64 Middle Man: Refactoring Second step : For each client use of a delegated method, remove the method from the middle man and replace the call in the client to call a method directly on the delegate Last step : Compile and test. client class Person getManager() getDepartment() Department getManager() client class Person getManager() getDepartment() Department getManager() Manager = john.getDepartment().getManager();
  • 65. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments 65
  • 66. Switch Statements Switch statements (“cases”) often cause duplication adding a new clause to the switch requires finding
 all such switch statements throughout your code OO has a better ways to deal with actions depending on types: polymorphism ! Use Extract Method to extract the switch statement and then Move Method to get it into the class where polymorphism is needed. Then use Replace Conditional with Polymorphism after you setup the inheritance structure. 66* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 67. Primitive Obsession Characterised by a reluctance
 to use classes instead of
 primitive data types The difference between classes and primitive types is hard to define in OO Use Replace Data Value with Object on individual data value. Use Extract Class to put together a group of fields 67* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 68. Bad Smells : Classification The top crime Class / method organisation Large class, Long Method, Long Parameter List, Lazy Class, Data Class, … Lack of loose coupling or cohesion Inappropriate Intimacy, Feature Envy, Data Clumps, … Too much or too little delegation Message Chains, Middle Man, … Non Object-Oriented control or data structures Switch Statements, Primitive Obsession, … Other : Comments, … 68
  • 69. Some more bad smells Temporary Field Divergent Change Speculative Generality Alternative Classes with Different Interfaces Incomplete Library Refused Bequest Comments 69
  • 70. Temporary Field Instance variables that are only set sometimes are hard to understand; you expect an object to need all its variables. Use Extract Class to put the orphan variable and all the code that concerns it in one place. Use Introduce Null Object when the variable is just around to deal with the null special case. 70
  • 71. Divergent Change When one class is commonly changed
 in different ways for different reasons. When we make a change we want to be able to jump to a single clear point in the system and make the change. If you can’t do this you’ve got a bad smell. To clean this up you identify everything that changes for a particular cause and use Extract Class to put them all together. 71* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 72. Speculative Generality When someone says “I think
 we may need the ability to do
 this someday ” At this time you need all sorts of hooks and special cases to handle things that are not required Use Collapse Hierarchy – Inline Class – Remove Parameter – Rename Method 72* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 73. Alternative Classes with Different Interfaces Methods in different classes
 that do the same thing but
 have different signatures. Use Rename Method Keep using Move Method to move behaviour until protocols are the same 73* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 74. Incomplete Library Class When a library or framework class doesn't provide all the functionality you need But the solution to the problem, changing the library, is impossible since it is read-only. Use Introduce Foreign Method and Introduce Local Extension See details of these refactorings for more information on how they solve the problem 74
  • 75. Refused Bequest When a subclass ignores
 and doesn’t need most of
 the functionality provided
 by its superclass Can give confusion and problems You need to create a new sibling class and use Push Down Method and Push Down Field to push all the unused methods to the sibling. 75* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 76. Comments Are comments bad? Of course not! In general comments are a good thing to have. But… sometimes comments are just an excuse for bad code It stinks when you have a big comment which tries to explain bad code such comments are used as a deodorant to hide the rotten code underneath 76* Cartoon borrowed from https://sourcemaking.com/refactoring for didactic purposes only. *
  • 77. Comments: Example while (i<NRULES) { while (j<COL-1 && !(grammar[i][j+1].equals("N"))) { init(first); if (matrix[k][l] != 'R') { if (cs.indexOf(q)!=-1) { init(second); for (int p=0;p < stIndex.size();indexHeadGram++){ … « Look which rule to choose, and after we know which rule to take we initialize the array matrix with the correct value (depending on the rule). We do that until we have tested all rules and after that we … blablabla » 77
  • 78. Comments: Refactoring Patterns Using refactorings, our first action is to remove the bad smells in the commented code After having done this, we often find that the comments have become superfluous To avoid bad smells we can often use Extract Method Usually the name of the new method is enough then to explain what the code does 78
  • 79. Comments: Example public double price() { //price is base price – quantity discount + shipping return quantity * itemPrice – Math.max(0, quantity – 500) * itemPrice * 0.05 + Math.min(quantity * itemPrice * 0.1, 100.0) } public double price() {return basePrice – quantityDiscount + shipping } private double basePrice() {return quantity *itemPrice } private double quantityDiscount () {return Math.max(0, quantity – 500) * itemPrice * 0.05 } private double shipping () {Math.min(quantity * itemPrice * 0.1, 100.0) } Extract method 79
  • 80. Comments: Refactoring Patterns Sometimes the method is already extracted but still needs a comment to explain what it does One solution could be : Rename Method 80
  • 81. Comments: Example public double price() {return basePrice – Price2 + shipping } private double basePrice() {return quantity *itemPrice } private double Price2 () {return Math.max(0, quantity – 500) * itemPrice * 0.05 } private double shipping () {Math.min(quantity * itemPrice * 0.1, 100.0) } // Price2 represent the quantityDiscount 81 public double price() {return basePrice – quantityDiscount + shipping } private double basePrice() {return quantity *itemPrice } private double quantityDiscount () {return Math.max(0, quantity – 500) * itemPrice * 0.05 } private double shipping () {Math.min(quantity * itemPrice * 0.1, 100.0) } Rename method
  • 82. Comments: Refactoring Patterns A section of code assumes something about the state of the program. A comment is required to state the rule. To avoid it, we can use Introduce Assertion 82
  • 83. Comments: Example Public double getExpenseLimit() { // should have either expense limit or a primary project return (_expenseLimit != NULL_EXPENSE) ? _expenseLimit: _primaryProject.getMemberExpenseLimit(); } Public double getExpenseLimit() { assert.isTrue (_expenseLimit != NULL_EXPENSE || _primaryProject != null); return (_expenseLimit != NULL_EXPENSE) ? _expenseLimit: _primaryProject.getMemberExpenseLimit(); } Introduce Assertion 83
  • 84. Comments: Refactoring patterns (Summary) Bad comments Extract Method Rename Method Introduce Assertion No more bad comments 84
  • 85. Comments: some last remarks… When is a comment needed / useful ? Tip : Whenever you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous A good time to use a comment is when you don’t know exactly what to do A comment is a good place to say why you did something. This kind of information helps future modifiers, especially forgetful ones, including yourself A last case is to use comments when something has not been done during development 85
  • 86. C. CONCLUSION LINGI2252 – PROF. KIM MENS
  • 87. Problems with bad smells Only a good recipe book and nothing more It isn't always easy or even useful to use Sometimes depends on context
 and personal style / taste Most of them are specific to OO 87
  • 88. Conclusion To have a good habitable code: How? Refactorings When? Bad Smells Bad smells are only a recipe book to help us find the right refactoring patterns to apply 88
  • 90. BAD CODE SMELLS POSSIBLE QUESTIONS (1) ▸ Which bad smell could be corrected by applying the “Introduce Parameter Object” refactoring? ▸ Which refactorings would you probably apply to address the “Large Class” bad smell? ▸ Explain and illustrate one of the following bad smells: Long Method, Feature Envy or Middle Man. ▸ Explain the Long Parameter List bad smell in detail. Why is it a bad smell? How could it be solved with a refactoring? ▸ What’s the relation between the Long Parameter List bad smell and the Data Clumps bad smell?
  • 91. BAD CODE SMELLS POSSIBLE QUESTIONS (2) ▸ Explain and illustrate what the notion of “coupling” is. Should we strive for loose coupling or tight coupling? What bad smell describes a situation that violates this principle? Name and explain at least one. ▸ Explain and illustrate what the notion of “cohesion” is. Should we strive for low cohesion or high cohesion? What bad smell describes a situation that violates this principle? Name and explain at least one. ▸ Some bad smells are based on the principle that “things that change together should go together”. Explain one of these bad smells, and the principle on which they are based, in detail. ▸ Name and explain at least one bad smell that explains a problem related to bad use of inheritance. ▸ When talking about “Comments” in the bad smells theory session, it was stated that comments are sometimes just there because the code is bad. Can you give an example of this and how such comments could become superfluous simply by refactoring the code?