Can be inherited
and enhanced by
other developers
other than the
original author
Ask yourself if the code is “clean” enough
Slide 9
Slide 9 text
Clean Code Measurement
Slide 10
Slide 10 text
Owning a mess, is it worth?
Slide 11
Slide 11 text
What prevents clean code?
I’ll do the refactor later
Rule of the thumb
Spoiler alert: “Later” never comes
Slide 12
Slide 12 text
Owning a mess, is it worth?
Slide 13
Slide 13 text
Owning a mess, is it worth?
Slide 14
Slide 14 text
Owning a mess, is it worth?
Slide 15
Slide 15 text
Descriptive names
The name should always represent the developer’s idea
Slide 16
Slide 16 text
Meaningful names
Slide 17
Slide 17 text
Searchable names
Slide 18
Slide 18 text
Class names
Classes should have noun or noun phrase
names like Customer, WikiPage, Account,
AddressParser.
Avoid words like Manager, Processor, Data
… in the name of a class.
A class name should not be a verb.
Slide 19
Slide 19 text
Method names
Methods should have verb of verb phrase
names like post_payment, delete_page,
save.
Method names should say what they do!
Slide 20
Slide 20 text
Comments sometimes lie
Slide 21
Slide 21 text
Code never lies
Slide 22
Slide 22 text
Code never lies
Slide 23
Slide 23 text
If they don’t lie, they can be lazy
Crime: using a comment to avoid programming effort.
Slide 24
Slide 24 text
If they don’t lie, they can be lazy
Crime: using a comment to avoid programming effort.
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
Only one thing
Slide 27
Slide 27 text
Only one thing
Slide 28
Slide 28 text
Extract, extract, extract
Slide 29
Slide 29 text
Extract, extract, extract
Slide 30
Slide 30 text
Small cognitive/cyclomatic complexity
🙁
Slide 31
Slide 31 text
Small cognitive/cyclomatic complexity
😊
Slide 32
Slide 32 text
Advantages of measuring software complexity
1. Better Test Coverage
Slide 33
Slide 33 text
Advantages of measuring software complexity
3. Reduced Risk
Slide 34
Slide 34 text
Advantages of measuring software complexity
3. Lower Costs
Slide 35
Slide 35 text
Law of Demeter (“only 1 dot”)
Lieberherr, K.J.; Holland, I.M. (September 1989). "Assuring good style for object-oriented programs". IEEE Software. 6 (5): 38–48. doi:10.1109/52.35588.
Ask a dog to walk
🙅 book.pages().last().text()
Slide 36
Slide 36 text
Law of Demeter: drawbacks
it won't apply to cats
Slide 37
Slide 37 text
“Premature
optimisation is
the root of all
evil”
— Donald Knuth
Slide 38
Slide 38 text
Continuous Refactoring
“The most common “presenting” pathology in the hoarded
codebases I’ve seen — by far — is that developers don’t feel
they have time and/or permission to refactor code.”
— Sarah Mei
[Refactoring is] a very core technique to the whole agile way of
thinking because it
fi
ts in with the whole way in which we can
build software in a way that it can change easily … Refactoring
is central to this because refactoring is a disciplined way of
making changes. ”
— Martin Fowler
Slide 39
Slide 39 text
Tests matter
“How can I make sure that if I change this, nothing
else breaks?”
Slide 40
Slide 40 text
… also experience matter
Most popular code smells
Duplication Improper use of inheritance
Unnecessary complexity Convoluted Code
Useless/misleading comments Tight coupling
No Code Reviews
Over abstraction
Huge methods Design Pattern overuse
Poor naming No test
Commented code / code that’s not used Improper usage of private and public objects