05-Clean Code

DESIGN PRINCIPLES AND PATTERNS
05. CLEAN CODE

Nguyen Thi Thu Trang
trangntt@soict.hust.edu.vn
2
Content
1. Introduction Clean Code
Keep it Clean, Your Mother Doesn’t Work Here!
2. Meaningful Names
3. Clean Function/Method
4. Clean Class
5. Clean Test
3
1.1. What is Clean Code?

• Code must be easily readable
• Code must be easily understandable
• Code should be easily modified
… by anyone
Clean Code = Good Code

4
Why Clean Code?

Read code
• Programming is not what to 10%
tell the computer what to do

• Programming is what to tell to
another human what we want
the computer to do
• Unfortunately sometimes
the "other man" is ourselves
Write code
• Eventually we become authors 90%
Time programmers do at work
5
Why Clean Code? (2)

• There’s no such thing
as write-once code
• Bug Fixes
• Business Changes
• Enhancements
• New Functionality
6
What Prevents Clean Code?

• Number one reason:
“I’ll clean it up later”
• Pro Tip: “Later” never comes!

7
Going fast
”The only way to go fast, is to go well”
Robert C. Martin
• Don’t hack and skip testing just to finish at
the end of an iteration
• Write unit tests
• Fix the code
• Refactor
8
What is Bad Code (Code Smell)?

• Hard to read and understand
• Spaghetti code (things get wild within the component)
• Misleading
• Poor reusability
• It breaks when you change it
• Changes to component require inspecting/ modifying
more code
•è Low cohesion and Tight coupling

9
Review: Low Cohesion and Tight coupling

• Spaghetti code (things get wild within the
component)
• Poor reusability
• Changes to component require inspecting/
modifying more code
• Performance suffers
10
1.2. Code Smells and Refactoring

• Code smells (Bad smells):
Certain structures in the code
that suggest the possibility of
refactoring
• Refactoring means “to improve
the design and quality of
existing source code without
changing its external behavior”
Martin Fowler
• Unit tests guarantee that
refactoring preserves the behavior
Refactoring: The Typical Process
1. Save the code you start with
• Check-in or backup the current code
2. Prepare tests to assure the behavior after the
code is refactored
• Unit tests / characterization tests
3. Do refactoring one at a time
• Keep refactoring small
• Don't underestimate small changes
4. Run the tests and they should pass / else revert
5. Check-in (into the source control system)
1
1
Refactoring Tips
• Keep refactoring small
• One at a time
• Make a checklist
• Make a "later" / TODO list
• Check-in / commit frequently
• Add tests cases
• Review the results
• Pair programming
• Use tools/IDEs
• Visual Studio + add-ins / Eclipse + plugins / others 1
2
13
Java Refactorings in Eclipse

• Renaming resources
• Field, method, class, inner and anonymous class
• Moving to another package
• Class hierarchy modifications
• Make an interface/superclass from a class
• Code level mods
• Make a code segment a function
14
1.3. Main Principles for Clean Code

• Keep it simple: KISS principle
• Avoid duplication: DRY principle
• Avoid redundancy: YAGNI principle
• Boy scout rule
• Leave your code better than you found it
• Less coupling and more cohesion
• SOLID Principles (later)
• Law of Demeter
• Design Patterns (later)
15
D.R.Y Principle
• Don’t Repeat Yourself
• Applicable whenever we copy / paste a
piece of code
• Just use a method or a class
16
K.I.S.S Principle
• Keep It Simple and Stupid
• Whenever we want to implement a method to do
all things
17
Y.A.G.N.I principle
• You Ain’t Gonna Need It
• Don’t write methods which are not yet
necessary (may be you will never need
them)
• Unused classes, methods, parameters,
variables à remove them
• Somehow related with KISS
18
Law of Demeter
Karl Lieberherr i and colleagues
• Law of Demeter: An object should know as little as possible
about the internal structure of other objects with which it
interacts – a question of coupling
• Or… “only talk to your immediate friends”
• Closely related to representation exposure and
(im)mutability
• Bad example – too-tight chain of coupling between classes
general.getColonel().getMajor(m).getCaptain(cap)
.getSergeant(ser).getPrivate(name).digFoxHole();
• Better example
general.superviseFoxHole(m, cap, ser, name);
19
An object should only send messages to …

(More Demeter)
• itself (this) Guidelines: not strict rules!

But thinking about them
• its instance variables will generally help you
• its method's parameters produce better designs
• any object it creates
• any object returned by a call to one of this's methods
• any objects in a collection of the above
• notably absent: objects returned by messages sent to

other objects
20
S.O.L.I.D Principles
• SRP: The Single Responsibility Principle
• OCP: The Open Closed Principle
• LSP: The Liskov Substitution Principle
• ISP: The Interface Segregation Principle
• DIP: The Dependency Inversion Principle
21
Content
2. Meaningful Names
4. Clean Class
5. Clean Test
22
2.1. Use Intention-revealing Names

• A name of a variable, function/method, class should
reveal the intent
• Why it exists
• What it does
• How it is used
int d; // elapsed time in days
A name requires a comment è Does not reveal intent

23
Example
What is the purpose of this code?
• What kinds of things are in

theList?
• What is the significance of the zeroth
subscript of an item in theList?
• What is the significance of the value
4?
• How would we use the returned list?
24
Solution
• The simplicity of this code is not changed, but much more
meaningful
The power of choosing good names!

25
2.2. Avoid Disinformation

• Avoid false clues that obscure the meaning of
code
• For example: use accountList as variable name
but this variable is not actually a list
• Avoid giving similar names for different
variables:
• XYZControllerForEfficientHandlingOfStrings
• XYZControllerForEfficientStorageOfStrings
26
2.3. Make meaningful distinctions
What is the difference between two names: a1 and a2?

27
Avoid noise words

• 2 classes: ProductInfo & ProductData
• è Info and Data are noise words because they do not
reveal anything different
• 2 variables: zork & theZork
• How could we decide which variable should be used?
If names must be different, then they should

also mean something different!
28
2.4. Using pronounceable names
VS
29
2.5. Using searchable names

• Should give searchable names for a variable or constant
that are used in multiple places of code
Single letter and numeric constants are not easy to locate
VS
30
2.6. Class names

• Name of classes or objects should be noun or noun
phrase
• A class name should not be a VERB!
• Customer, Account, Address etc.
• Class name should also begin with a capitalized letter
31
2.7. Method names

• Methods should have verb or verb phrase names
• Accessors, mutators and predicates should be named
with prefix: get, set, is
• Should not capitalize the first letter of method name
• When constructors are overloaded, use static factory
methods with names that describe arguments
32
2.8. Add meaningful context

firstName
lastName
street
houseNumber form an address
city
state
zipcode
è They should belong to the class Address?
33
Practice: Clean code with meaningful

names
• Checking if the codebase are clean with
meaningful names
• If not, re-design and re-factor
34
Content
2. Meaningful Names
4. Clean Class
5. Clean Test
35
3.1. Do ONE Thing

• Functions should do one thing => Cohensive
They should do it well
They should do it only
• How to know what “one thing” is?

• A function is doing more than “one thing” if you
can extract another function from it with a name
that is not merely a restatement of its
implementation
• ONE Thing: ONE Level of Abstraction
36
ONE Level of Abstraction

• A function with these three steps does one,
two or three things?
• Determining whether the page is a test page
• If so, including setups and teardowns
• Rendering the page in HTML
public static String testableHtml(PageData pageData, 37
boolean includeSuiteSetup) throws Exception{
WikiPage wikiPage = pageData.getWikiPage(); //very high level
StringBuffer buffer = new StringBuffer();
if (pageData.hasAttribute("Test")){
if (includeSuiteSetup){ ... }
...
}
buffer.append(pageData.getContent());
HtmlUtil.java (v1)
if (pageData.hasAttribute("Test")){
WikiPage teardown = ...
...
buffer.append("\n"); //low level
... Multiple levels of
}
if (includeSuiteSetup) { abstraction
WikiPage suiteTeardown = ...
...
String pagePathName = PathParser.render(pagePath); //intermediate
...
}
pageData.setContent(buffer.toString());
return pageData.getHtml(); //very high level
}
38
HtmlUtil.java (v2)
public static String renderPageWithSetupsAndTeardowns(
PageData pageData, boolean isSuite) throws Exception{
boolean isTestPage = pageData.hasAttribute("Test"); //low
if (isTestPage){
WikiPage testPage = pageData.getWikiPage(); // high
StringBuffer newPageContent = new StringBuffer();
includeSetupPages(testPage, newPageContent, isSuite);
newPageContent.append(pageData.getContent();
includeTeardownPages(testPage, newPageContent, isSuite);
pageData.setContent(newPageContent.toString());
}
return pageData.getHtml(); Two levels of
}
abstraction
39
HtmlUtil.java (v3)
public static String renderPageWithSetupsAndTeardowns(
PageData pageData, boolean isSuite) throws Exception{
if (isTestPage(pageData))
includeSetupAndTeardownPages(pageData, isSuite);
return pageData.getHtml();
}
ONE level of abstraction

• You can’t extract another function from it
with a name that is not merely a
restatement of its implementation
Clean for Cohensive Functions/Methods
• Large repeating code fragments à extract
duplicated code in separate method
• Large methods à split them logically
• Large loop body or deep nesting à extract
method
• Method has weak cohesion à split into several
methods
4
0
41
3.2. Loosely Coupled Functions/Methods

• Avoid Flag arguments (Control coupling)
• Passing a boolean into a function is a truly terrible
practice: Function does one thing if the flag is true and
another if the flag is false
if (delPage(page) == E_OK) { 42
if (registry.deleteRef(page.name) == E_OK) {
if(configKeys.deleteKey(page.name.makeKey())
== E_OK){
logger.log("page deleted");
} else {
logger.log("configKey not deleted");
}
} else {
logger.log("deleteReference from registry failed"); }
}else {
logger.log("delete failed");
return E_ERROR;
}
try {
deletePage(page);
registry.deleteRef(page.name);
configKeys.deleteKey(page.name.makeKey());
} catch (Exception e) {
logger.log(e.getMessage());
}
43
3.2. (cont.)
• Extract Try/Catch Blocks
• Try/Catch mixes error processing with normal processing
Error Processing
• Extract bodies of try/catch out into separated functions
Nice Separation of functions!!!
the processes of fully deleting a page

44
3.2. (cont.)
• Prefer Exceptions to Returning Error Codes
(Control Coupling)
This method returns a special

value that indicates an error?
45
3.2. (cont.)
• Prefer Exceptions to Returning Error Codes
(Control Coupling) – Benefits:
1. No more code for checking various error codes
2. Exception classes can implement their own method,
i.e., error handling functionality
3. Error codes can’t be used in a constructor, since a
constructor must return only a new object
46
3.2. (cont.)
• Have No Side Effect
• Not do hidden things
• Side Effect: Make unexpected changes to the variables
of its own class or parameters or global data (Common
coupling)
47
This function matches a username and a password.

Does it contain any side effects?
48
Temporal coupling: what if checkPassword() is called out

of order checkout?
49
Clean for Loosely Coupled Functions

• Public non-constant fields à make them private
and define necessary accessing properties
Why we should refactor public field?

50

A method calls more methods from another class
than from its own class à Move it
WHY?
51

A method calls more methods from another class
than from its own class à Move it
• Classes are more internally coherent

• Reduce dependency between classes
52

A method has too many parameters
53

Problems:
• A high-couling in function because each
parameter has its own goal
Solutions:
1) Replace Parameter with Method Call
2) Introduce Parameter Object
54
Replace Parameter with Method Call

• If some of the arguments are results of method calls of
another object
int basePrice = quantity * itemPrice;

double seasonDiscount = this.getSeasonalDiscount();
double fees = this.getFees();
double finalPrice = discountedPrice(basePrice, seasonDiscount,
fees);
int basePrice = quantity * itemPrice;

double finalPrice = discountedPrice(basePrice);
55
Introduce Parameter Object

• If there are several unrelated data elements, it is better to
merge them into parameter object
56
3.3. Method Refactoring

• Data-Level Refactoring
• Statement-Level Refactoring
• Method-Level Refactoring
Data-Level Refactoring
• Rename a variable with more informative name
• Replace a magic number with a named constant
• Reduce duplicate use of a number or string in the code

• Easier to change the value of a constant than to search for this number 5
throughout the entire codebase 7
Replace an expression with a method
• To simplify it or avoid code duplication
5
8
Move an expression inline
• Improve the readability of the program by getting rid of the unnecessary variable
5
9
Introduce an intermediate variable
• Introduce explaining variable
More readable code!!!
Drawbacks?
6
0
Convert a multi-use variable to a multiple single-use
variables
• Create separate variable for each usage
Each component does one thing, no more than one thing!

6
1
Convert a data primitive to a class
• Improve realtedness inside classes
• Data and relevant behaviors are inside a single class
What if the field customer has its own

behavior and associated data?
6
2
Convert a set of type codes (constants) to enum
What is type code? A set of numbers or strings that form a list of

allowable values for some entity.
6
3
Convert a set of type codes (constants) to enum/class
Problem: A class has a field that contains type code
What if someone sends unintended or wrong values

to the filed bloodgroup?
6
4
Convert a set of type codes to a class with subclasses with
different behavior
Problem Context: You have a method that accepts one of
the type values in the parameters (i.e., user),
USER_TYPE_ADMIN = “ADMIN”
if (user.getType) === UserType.USER_TYPE_ADMIN
doSomething()
What if the method receives the same string but in lower case “admin”?
6
5
Convert a set of type codes to a class with subclasses with
different behavior
Benefits:
• Delete control flow code by moving the code to appropriate subclasses
• Need to add a new value for a coded type è Add new subclass, so OCP!
6
6
What if:
• your type code affects the behavior of a class
• the value of coded type can be changed during the
object’s lifetime?
You cannot use:
• Replace Type Code with Class/Enum
• Replace Type Code with Subclasses
Solution: Strategy/State Pattern
6
7
Replace type code by Strategy/State
If a new value of a coded type is needed, just create a new state subclass!
6
8
Change an array to an object
• When you use an array with different goals for each element
What if we put something in the wrong element?
Solution: Replace the array with an object that will have separate
fields for each element.
6
9
Encapsulate a collection
Problem: A class contains a collection field and a simple getter/setter for working
with this collection
• Client can change the collection content

without the knowledge of the owner class
• Should not assign a value to a collection
7
0
71
Statement-Level Refactoring
• Decompose a boolean expression
• Move a complex boolean expression into a well-
named boolean function
72
• Consolidate Conditional Expression
• Multiple conditionals that lead to the same
result or action
73
• Consolidate duplicated code in conditionals
74
Return as soon as you know
the answer instead of
assigning a return value
75
Replace conditionals with polymorphism
Problem: We have a conditional that performs various actions depending on
object type or properties
76
Tell don’t Ask:

• Dont ASK an object about its state
and then performing actions based
on this
• Just TELL the object what it needs
to do and let it decide for itself
HOW to do that
77
Use null-object design pattern instead of
checking for null
Need ALWAYS to check for null in your

code to avoid Null Pointer Exception
78
Method-Level Refactoring
• Extract method / inline method
• Rename a method
• Convert a long routine to a class
• Add / remove parameter
• Combine similar methods by parameterizing them
• Substitute a complex algorithm with simpler
• Separate methods whose behavior depends on
parameters passed in (create new ones)
• Pass a whole object rather than specific fields
• Encapsulate downcast / return interface types
79
Practice: Clean Method

• Checking if all methods in codebase are
clean
80
Content
2. Meaningful Names
4. Clean Class
5. Clean Test
81
Signs of Code Smells in Class

• Large class
• Classes usually start small, but get bloated as
the program grows
• Often does more than one task è more than
one reason to change it
82
Signs of Code Smells in Class (2)

• Refused bequest
• Subclass uses only some of the methods and
properties inherited from its parents
83

• Alternative Classes
with Different
Interfaces
• 2 classes perform
identical functions
but have different
method names
84

• Divergent change
• Make changes to a class requires change many
unrelated methods
• For example, when adding a new product type you have to change
the methods for finding, displaying, and ordering products.
85

• Shotgun Surgery
• A single change is made to multiple classes
simulteneously
86

• Parallel Inheritance Hierarchies
• Whenever creating a subclass for a class, it
requires to create a subclass for another class
87

• Inappropriate Intimacy
• One class uses the internal fields and methods of
another class
• Good designed classes should know as little as
possible about each other
88

• Incomplete library class
• The library does not provide a feature you need
and it is impossible to modify the library to
implement it
89
Practice: Checking code smells in

codebase
• Checking if there are signs of code smell in
all classes of the codebase
90
4.3. Class Refactoring

• Class-Level Refactoring
• Interface-Level Refactoring
• System-Level Refactoring
91

Restructure class
• Pull up field / method
• When there is a duplication of field, method in subclasses è
move them up to superclass
9
2
Restructure class
• Pull up constructor body
• Your subclasses have constructors with code that’s mostly
identical
9
3
Restructure class
• Push down field/method
• If some members of superclass are used only in a few
subclasses
9
4
Extract subclass
• Code smell: a class has features that are used only in
certain cases
• Solution: create a subclass and use it in these cases
• Case study:
• Car class, you had field isElectricCar and depending on
it, in the refuel() method the car is either fueled up with gas
or charged with electricity.
9
5
96
Extract superclass
• Code smell: two
classes with common
fields and methods
(duplication code)
• Solution: create a
superclass containing
all duplication code
97
Extract superclass
• Code smell: two
classes with common
fields and methods
(duplication code)
• Solution: create a
superclass containing
all duplication code
98
Collapse Hierarchy
• Code smell: Subclass is practically the same as its
superclass
• Solution: Merge the subclass and superclass
99
Form Template Method

• Problem: Your subclasses implement algorithms that
contain similar steps in the same order.
• Solution: Move the algorithm structure and identical
steps to a superclass, and leave implementation of the
different steps in the subclass
100
Form Template Method (2)

• Case study:
101
Form Template Method (3)

• Solution:
Replace Inheritance with Delegation
• Problem: A subclass that uses only a portion of the
methods of its superclass (or it is impossible to inherit
superclass data)
• Why refactor?
• The subclass violates the LSP
• Solution:
• Create a field and put a superclass object in it, delegate
methods to the superclass object, and get rid of inheritance
1
0
Replace Inheritance with Delegation (2)
• Case study:
1
0
• Case study:
1
0
• Case study: A navigation application for casual
travelers
1
0
• Solution: Inheritance. Is it good enough?
1
0
• Solution: Delegation
Strategy Pattern
1
0
Replace Delegation with Inheritance
• Problem: A class contains many simple methods that
delegate to all methods of another class
1
0
Replace Delegation with Inheritance
• Solution: Make the class a delegate inheritor, which makes the
delegating methods unnecessary
• When not to use?
1
0
110

Extract interfaces
• Problem: Multiple clients are using the same
part of a class interface or part of the interface
in two classes is the same
• Solution: move this identical portion to its own
interface
• Interfaces are very apopos when classes play
special roles in different situations
1
1
Extract interfaces (2)
• Case study
1
1
Hide delegate
• Problem: The client gets object B from a field or
method of object A, then the client calls a
method of object B
• Code smell: message chain
• a.b().c().d()
• Why refactoring?
• a: server – the object to which the client has direct access
• c(): return an object – delegate – the end object that
contains the functionality needed by the client
• These sequences of calls involve the client in navigation
along the class structure, any changes in these 1
interrelationships will require changes on the client side 1
Hide delegate (2)
• Solution: Create a new method in class A that delegates
the call to object B
manager = aPerson.getDepartment().getManager() 1
1
Hide delegate (3)
• Solution: Create a new method in class A that delegates
the call to object B
• Benefit?
manager = aPerson.getManager()
return this.department.manager
1
1
Remove Middle Man
• Problem: A class has too many methods that
simply delegate to objects of other classes
• Result from the elimination of Message Chains
• Solution: Delete these methods and force the
client to call the end methods directly
1
1
Introduce Foreign Method
• Problem: A utility class doesn’t contain the method
that you need and you can’t add the method to the
class
1
1
Introduce Foreign Method (2)
• Solution: Add the method to a client class and
pass an object of the utility class to it as an
argument
What if you want to reuse this method in other classes? 1

1
Introduce Local Extension
• Problem: A utility class doesn’t contain some
methods that you need and it is impossible to add
these methods to this class
You want to reuse this method in

other classes
1
1
Introduce Local Extension (2)
• Solution: Create a new class
containing the methods and
make it either the child or
wrapper of the utility class
• Create subclass: inherit from
the utility class
• Create wrapper class: when
the utility class prevent
inheritance (with final)
• Apply Decorator pattern
1
2
Using Decorator to resolve the Incomplete
Library Class Code Smell
• Decorator is also known as – a structural pattern
• Intent: Attach new behaviors to objects by placing these
objects inside special wrapper objects or via inheritance
• Case stydy:
• In your application, you use a notification library which lets other
programs notify their users about important events
• The base library allows you to send notification email
1
2
Library Class Code Smell (2)
• Case stydy:
• Problem: You need other kinds of notification than just email
notification
• You just inherit the base class Notifier
1
2
• Case stydy:
• What if someone asks you to provide notification on multiple
channels?
1
2
• Case stydy:
• What if someone asks you to provide notification on multiple
channels?
! ! !
ps
Oo
1
2
• Case study – Solution: Using Aggregation or Composition
instead Inheritance
1
2
• Case study – Solution: We
leave the simple email
notification inside the base class
Notifier and turn all other
notification methods into
decorators
wrappee = notifier
1
2
• How does the client work?
• Client wraps a basic notifier
object into a set of decorators
that match the client’s
preferences
• The resulting object will be
structured as a stack
1
2
128

System-Level Refactoring
• Move class (set of classes) to another
namespace / assembly
• Provide a factory method instead of a simple
constructor / use fluent API
• Replace error codes with exceptions
• Extract strings to resource files
• Use dependency injection
• Apply architecture patterns
1
2
130
Practice: Clean Class

• Checking if all classes in codebase are
clean
131
Content
2. Meaningful Names
4. Clean Class
5. Clean Test
132
5.1. Unit Tests

• Instant feedback
• Allows you to make changes to
code quickly
• Help you understand the design
of the code you are working on
• Writing testable code helps to
achieve better code quality
• Unit tests are a form of sample
code
• Test-first forces you to plan
before you code
133
Bug handling
1. Write a test that proves the existense of the bug
2. Fix the code and watch the test pass
à Automated regression testing
• Security benefit
• If we find a bug somewhere, we can make sure it does
not reappear
134
Testing, clean code and security

• Well-tested code gives us assurance and
confidence in our code base
• Well-tested code is easy to change
• We have a safety net
• Changeable code allows us to refactor
• Clean code
• Change design – improve the architecture
• Improve the readability
135
Testing, clean code and security (2)

• Clean readable code is easier to understand
”Comments are a failure to express oneself in code”
Robert C. Martin (paraphrased)
• Understandable code is easier to secure
• Security tests give us assurance and confidence
in our security controls
• Regression testing
• OWASP ESAPI
136
The Three Laws of TDD

• First Law: You may not write production code
until you have written a failing unit test.
• Second Law: You may not write more of a unit
test than is sufficient to fail, and not compiling is
failing.
• Third Law: You may not write more production
code than is sufficient to pass the currently failing
test
137
5.2. Clean Test

• Even more important in unit tests than it is
in production code
• How?
• Readability,
• Readability and
• Readability
• How?
• Clarity,
• Simplicity
• Density of expression
138
SerializedPageResponderTest.java
public void testGetDataAsHtml() throws Exception {
crawler.addPage(root, PathParser.parse("TestPageOne"), "test page");
request.setResource("TestPageOne");
request.addInput("type", "data");
Responder responder = new SerializedPageResponder();
SimpleResponse response =
(SimpleResponse) responder.makeResponse(
new FitNesseContext(root), request);
String xml = response.getContent();
assertEquals("text/xml", response.getContentType());
assertSubString("test page", xml); assertSubString("<Test", xml);
}
Clean Test: Readability

SerializedPageResponderTest.java (refactored)
public void testGetDataAsXml() throws Exception {
makePageWithContent("TestPageOne", "test page");
submitRequest("TestPageOne", "type:data");
assertResponseIsXML();
assertResponseContains("test page", "<Test");
}
139
5.3. One Assert per Test

• Easy to understand
• A single conclusion that is quick
EnvironmentControllerTest.java
@Test
public void turnOnCoolerAndBlowerIfTooHot() throws
Exception{
tooHot();
assertEquals("hBChl", hw.getState());
}
@Test
public void turnOnHeaterAndBlowerIfTooCold() throws
Exception{
tooCold();
assertEquals("HBchl", hw.getState());
}
140
One Assert per Test: Break into separate tests

SerializedPageResponderTest.java (refactored)
public void testGetDataAsXml() throws Exception {
makePageWithContent("TestPageOne", "test page");
submitRequest("TestPageOne", "type:data");
assertResponseIsXML();
assertResponseContains("test page", "<Test");
}
SerializedPageResponderTest.java (Single Assert)
public void testGetPageHierarchyAsXml() throws Exception{
givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
whenRequestIsIssued("root", "type:pages");
thenResponseShouldBeXML();
}
public void testGetPageHierarchyHasRightTags() throws Exception{
givenPages("PageOne", "PageOne.ChildOne", "PageTwo");
whenRequestIsIssued("root", "type:pages");
thenResponseShouldContain(
"<name>PageOne</name>",
"<name>PageTwo</name>","<name>ChildOne</name>");
}
141
5.4. Single Concept per Test

• No more than one concept being tested
• Not long test functions that go testing one
miscellaneous thing after another
• May be multiple asserts for one concept
è Minimize the number of asserts per concept

and test just one concept per test function
142
Break into separate test functions

public void testAddMonths() {
SerialDate d1 = SerialDate.createInstance(31, 5, 2004);
SerialDate d2 = SerialDate.addMonths(1, d1);

assertEquals(30, d2.getDayOfMonth()); è Break
assertEquals(6, d2.getMonth());
assertEquals(2004, d2.getYYYY());
into
three
SerialDate d3 = SerialDate.addMonths(2, d1); test
assertEquals(31, d3.getDayOfMonth()); functions
SerialDate d4 = SerialDate.addMonths(1,
SerialDate.addMonths(1, d1));
assertEquals(30, d4.getDayOfMonth());
}
143
5.5. F.I.R.S.T
• Fast: Tests should be fast.
• To run them frequently
• Independent: Tests should not depend on each other
• One test should not set up the conditions for the next test
• Able to run each test independently and run the tests in any order
• Repeatable: Tests should be repeatable in any environment
• Able to run the tests in development, testing, production, QA
environment… without a network.
• Self-Validating: The tests should have a boolean output
either they pass or fail.
• Make the failure objective, not subjective (not manlually)
• Timely: The tests need to be written in a timely fashion
• Unit tests should be written just before the production code that makes
them pass
144
Practice: Clean Test

• Checking if all unit tests in codebase are
clean

05-Clean Code

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05-Clean Code

Uploaded by

Copyright:

Available Formats

DESIGN PRINCIPLES AND PATTERNS

05. CLEAN CODE

1.1. What is Clean Code?

Clean Code = Good Code

Why Clean Code?

tell the computer what to do

Why Clean Code? (2)

What Prevents Clean Code?

“I’ll clean it up later”

• Pro Tip: “Later” never comes!

What is Bad Code (Code Smell)?

•è Low cohesion and Tight coupling

Review: Low Cohesion and Tight coupling

1.2. Code Smells and Refactoring

Java Refactorings in Eclipse

1.3. Main Principles for Clean Code

An object should only send messages to …

• itself (this) Guidelines: not strict rules!

• notably absent: objects returned by messages sent to

2.1. Use Intention-revealing Names

int d; // elapsed time in days

A name requires a comment è Does not reveal intent

• What kinds of things are in

The power of choosing good names!

2.2. Avoid Disinformation

2.3. Make meaningful distinctions

What is the difference between two names: a1 and a2?

Avoid noise words

If names must be different, then they should

2.4. Using pronounceable names

2.5. Using searchable names

Single letter and numeric constants are not easy to locate

2.6. Class names

2.7. Method names

2.8. Add meaningful context

Practice: Clean code with meaningful

3.1. Do ONE Thing

• How to know what “one thing” is?

ONE Level of Abstraction

ONE level of abstraction

3.2. Loosely Coupled Functions/Methods

Nice Separation of functions!!!

the processes of fully deleting a page

This method returns a special

This function matches a username and a password.

Temporal coupling: what if checkPassword() is called out

Clean for Loosely Coupled Functions

Why we should refactor public field?

Clean for Loosely Coupled Functions

Clean for Loosely Coupled Functions

• Classes are more internally coherent

Clean for Loosely Coupled Functions

Clean for Loosely Coupled Functions

Replace Parameter with Method Call

int basePrice = quantity * itemPrice;

int basePrice = quantity * itemPrice;

Introduce Parameter Object

3.3. Method Refactoring

• Reduce duplicate use of a number or string in the code

More readable code!!!

Each component does one thing, no more than one thing!

What if the field customer has its own

What is type code? A set of numbers or strings that form a list of