Clean Code in practice

"Continuous attention to technical excellence and good design enhances agility." 9th principle of Agile Manifesto.

Why is it so important to take care of code cleanness ? What are the major "code smells" which taint our code ? And how to clean or avoid them? Come find some answers to these questions (live code inside :).

ITAKE Unconference, Bucharest, 2013. http://www.itakeunconf.com

Transcript

1. CLEAN CODE IN PRACTICE / Antoine Vernois @avernois
2. a.b.c.d THANKS ITAKE ORGANIZERS JÉRÔME AVOUSTIN YOU !
3. ANTOINE VERNOIS Journeyman @avernois
6. DISCLAIMER Object Oriented Language I won't go into details Some points will look stupidly simple I will repeat myself
7. AGILE & QUALITY Continuous attention to technical excellence and good design enhances agility. Agile Manifesto, 9th principle
8. WHY QUALITY ?
9. AGILE & QUALITY (AGAIN) Responding to change over following a plan. Agile Manifesto, 4th value
10. WHAT IS QUALITY ? A software is of good quality if the cost to add a feature does not change over time. Jérôme Avoustin
11. WHAT IS A CLEAN CODE ? Clean code is not about beautifullness, it's about goodness. Rebecca Wirfs-Brock tested ! no duplication reveals its intention easy to read B. Stroustrup, R. Jeffries, K. Beck, M. Feathers, W. Cunningham, ...
12. ABOUT TESTS When I hear tests are for those who don't know how to code
13. SMELLS
14. SMELLS Singleton Tight coupling Untestable Premature Optimisation Indescriptive naming Duplication
15. GOOD PRACTICES
16. GOOD PRACTICES Single Responsability Open-closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
17. GOOD NAMING names should reveal the intent alt+shift+r is your friend (in eclipse) ... LET'S SEE FOR REAL.
18. DUPLICATION DON'T REPEAT YOURSELF !
19. ABSTRACTION 1 LEVEL BY METHOD
20. ABSTRACTION DEMETER'S LAW DON'T TALK TO STRANGER a . g e t B ( ) . g e t C ( ) . d o T h i n g s ( ) ;
21. TIGHT COUPLING IT'S BAD ! Tests Reuse ...
22. DEPENDANCY INJECTION p u b l i c c l a s s A { p r i v a t e B b ; p u b l i c v o i d e x e c u t e ( i n t i ) { b = n e w B ( ) ; C c = n e w C ( ) ; i f ( i < = 3 ) { b . e x e c u t e B ( ) ; } e l s e { c . e x e c u t e C ( ) ; } } }
23. METHODS SHORT
24. COMMENTS Comments are always failure Uncle Bob Don't comment bad code. Rewrite it. Brian W. Kernighan, P.J. Plaugher
25. COMMENTS FROM REAL LIFE / * * A c o m m e n t t o p l e a s e c h e c k s t y l e * / / * * S e t t h e p o r t * * @ p a r a m s p o r t * / p u b l i c v o i d s e t P o r t ( P o r t p o r t ) { t h i s . p o r t = p o r t } . . . } / * e n d f o r * / d a o . f l u s h ( ) ; d e f a u l t : b r e a k ; } / * e n d s w i t c h * / } / * e n d i f * / } / * e n d i f * / } c a t c h . . .
26. COMMENTS : THE EXCEPTION EXPLAIN THE WHY !
27. COMMENTS TEST TELLS ME WHAT CODE TELLS ME HOW COMMENT, IF NEEDED, TELLS ME WHY
28. HANDLING EXCEPTION FAIL FAST 1. Do not check exception 2. Manage exception as high as possible 3. Never ever return null !
29. TESTS The give you confidence to change the code. one test, one assert readibility tests document your code A TEST SHOULD TELL YOU A STORY TESTS ARE FIRST CLASS CITIZEN !
30. SOME MORE ADVICES Don't think inheritance, think polymorphism Don't think if/switch, think polymorphism AVOID SINGLETONS Did i warn you i will repeat myself ?
31. READ LIST
33. QUOTES Any fool can write code that a computer can understand. Good programmers write code that human can understand. Martin Fowler Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Martin Golding ...if you're afraid to change something it is clearly poorly designed. Martin Fowler
34. AND ALL OF THIS, IT STARTS NEXT TIME YOU'LL READ OR WRITE CODE
35. THANK YOU ! ANY QUESTION ?