Clean Code talk held at the HSR "Hochschule für Technik Rapperswil" and the FHNW "Fachhochschule Nordwestschweiz" based on the great book by Robert C. Martin and enriched with personal experiences

1. CLEAN CODE
IT REALLY MATTERS
BROUGHT TO YOU
BY
SENIOR SOFTWARE
ENGINEER
DANIEL
KUMMER
NAMICS AG ZÜRICH
WWW.NAMICS.COM

2. CLEAN CODE
AGENDA
?
WHY
DOES IT EVEN
MATTER?
!
HOW
CAN IT BE
DONE?
*
BESIDE
THE CODE…

3. DEFINITION
OF CLEAN CODE
WORKS
EFFICIENT
READABLE
EXTENDABLE
CORRECTLY
IT TELLS YOU A STORY
SIMPLE
TO UNDERSTAND
IT DOES IT RIGHT
EASY TO MODIFY
CLEAN
SOMEONE CARED

4. ?
WHY
CARE
”The only valid code metric is WTFs
per minute” ~ A comic strip

5. SOFTWARE
ENTROPY
THE BROKEN WINDOW
DON’T LIVE WITH
BROKEN WINDOWS!

6. IT’S ALL
ABOUT
$$$
THE COST OF
BAD CODE
TIME
PRODUCTIVITY
NERVES
PROJECTS
Mo$va$on
No
one
wants
to
take
it

7. DETECTING
BAD CODE
DEAD CODE
UNUSED = UNNEEDED
COMMENTS
WHY NOT WHAT
A FEW
SMELLS
DUPLICATES
DON’T REPEAT YOURSELF
CONDITIONAL LONG METHOD / SPECULATIVE
COMPLEXITY PARAMETER LIST GENERALITY
HARD TO TEST
SHORTER = EASIER
SOLVE TODAYS PROBLEM,
NOT TOMORROWS
A more complete list can be found at http://www.codinghorror.com/blog/2006/05/code-smells.html

8. !
HOW
TO DO IT
“Any fool can write code that a computer
can understand.
Good programmers write code that
humans can understand.” ~Martin Fowler

9. 2
SIMPLE
RULES
EASY TO FOLLOW

10. 1
WRITE DIRTY CODE
FIRST, THEN CLEAN IT
YOU CAN’T WRITE CLEAN CODE ON THE FIRST GO!
YOUR FIRST ATTEMPT WON’T BE YOUR BEST
SUCCESSIVE REFINEMENT IS KEY
START WITH PSEUDOCODE

11. 2
LEAVE IT CLEANER
THAN YOU FOUND IT
THE “BOYSCOUT” RULE
INCREMENTIALISM – MAKE TINY CHANGES
EVEN IF IT’S JUST REFORMATTING – YOU CARED
YOU ARE TAKING RESPONSIBILITY

12. THREE WORDS
CARE FOR CODE

13. CLEAN
TIPPS
HOW TO GO ABOUT IT

14. NAMING CONVENTIONS
REVEAL INTENTION – CLARITY IS KING
no questions asked about the purpose
LONG NAMES AREN’T BAD
pick names corresponding to the scope
ONE WORD PER CONCEPT / NOT AMBIGUOUS
keep the lexicon consistent
USE ENGLISH – DON’T USE YOUR LANGUAGE
just don’t!

15. CODING
DRY - DON’T REPEAT YOURSELF
duplication is a root of evil!
DON’T OPTIMIZE PREMATURELY
unless it’s really, really necessary
DON’T SAVE ON CHARACTERS
one liners are not faster, just unreadable
DON’T TRY TO OUTSMART THE COMPILER
really smart people are working on it…

16. FUNCTIONS
KISS - KEEP IT SIMPLE AND STUPID
equals understandable
DO ONE THING ONLY – AND DO IT WELL
keep the level of abstraction to a minimum
MINIMIZE ARGUMENTS – LESS IS MORE
pursue it, as best as you can (think about testing)

17. FUNCTIONS
FLAGS ARE BAD
prefer polymorphism
SIDE EFFECTS ARE SCARY
the function should do one thing
EXTRACT ERROR HANDLING
improve readability, don’t obscure logic
RETURN ONCE ONLY – OR FAIL FAST
keep the exit clear

18. COMMENTING //drunk, fix later
NEVER EXPLAIN WHAT CODE DOES
explain WHY you did it this way
DON’T COMMENT OUT CODE
we have VCS for this!
COMMENT STRANGE OR UNNATURAL CODE
do it even if it’s not your own – explain why
NO REDUNDANT OR MANDATED COMMENTS
example: don’t document getters / setters

19. FORMATTING DO IT LIKE THE NEWSPAPERS
{
TOP-DOWN PRINCIPLE
MAIN FUNCTIONS ON TOP
FOLLOWED BY CALLED FUNCTIONS
}
VERTICAL DENSITY
WHAT BELONGS TOGETHER
SHOULD BE TOGETHER
NO HORIZONTAL ALIGNMENT
DON’T ALIGN JUST FOR THE LOOKS

20. OBJECTS AND CLASSES
SRP – SINGLE RESPONSIBILITY PRINCIPLE
one responsibility per object
SMALL
keep away from the “god”-classes
ORGANIZE FOR CHANGE – USE INTERFACES
it’s most likely going to happen
LoD - LAW OF DEMETER (LOOSE COUPLING)
a given object should assume as little as possible
about the structure or properties of anything else

21. ERROR HANDLING
USE UNCHECKED EXCEPTIONS AND
DOCUMENT THEM IN THE JAVADOC
you decide when to handle them
EXTRACT HANDLING BLOCKS (TRY/CATCH)
don’t disturb the code flow
DON’T RETURN NULL, DON’T PASS NULL
avoid NULL checks and NPEs
CONCENTRATE ON WHAT YOU CAN HANDLE
not what to throw

22. TEST
YOUR CREATION
SO YOU MAY SLEEP CALM AT NIGHT

23. THE F.I.R.S.T PRINCIPLE
FAST
tests should run quick – or you won’t run them
INDEPENDENT
no test should depend on another test
REPEATABLE
in any environment, your laptop, the CI server…
SELF-VALIDATING
pass or fail - no manual action required
TIMELY
don’t write your tests too late, it only gets harder

24. TESTING PYRAMID

25. BESIDE
CODE
THE SATELLITES OF
A SOFTWARE PROJECT

26. USE TOOLS
COMBINE YOUR MAGIC HELPERS
CONTINUOUS INTEGRATION
EARLY PROBLEM RECOGNITION
RELEASE MANAGEMENT
SCM / VSC
ISSUE MANAGEMENT
CODE METRICS
DEFINE YOUR RELEASE CYCLES
TRACK DISCUSSIONS AND DESCISSIONS
KEEP A CLEAR HISTORY
HEURISTIC CODE ANALYSIS

27. HUMAN FACTORS
DON’T BE SHY…
OTHERS HAVE THE SAME PROBLEMS YOU HAVE – EVEN PROS!
REVIEW
LEARN
DISCUSS
SHARE
IMPROVE AND LEARN
GUIDELINES / PROBLEMS / SOLUTIONS
DELIBERATE PRACTICE
THOUGHTS / TOOLS / IDEAS

28. GOING
DEEPER
more about everything…

29. READING MATERIAL
SOFTWARE
CRAFTSMANSHIP
CODE OF CONDUCT
CLEAN YOUR CODE
WITH COMMON
SOLUTIONS

30. CLEAN CODE
DEPENDS ON
YOU