© Copyright SELA Software & Education Labs, Ltd. | 14-18 Baruch Hirsch St., Bnei Brak, 51202 Israel | www.selagroup.com

SELA DEVELOPER PRACTICEMay 31st – June 4th, 2015

Noam KfirClean Code

writing codeis fun and easy

or it should be

writing code is fun and easy

Programmers are problem solvers

writing code is fun and easy

Programmers are optimistic

writing code is fun and easy

Programmers are lazy

developmentis usually pretty

hardbut it shouldn’t be

development is hard

Programmers build systems, not puzzles

development is hard

Programmers don’t work alone

development is hard

Programmers have deadlines

so wecut corners

hey, it’s not our fault

cutting corners

Programs acquire bugs

cutting corners

Programs accrue technical debt

cutting corners

Programs become difficult to maintain

cutting corners

Customers become unhappy

Managers, testers, support personnel all become unhappy

Programmers become unhappy

clean codeto the rescue

it’s (probably) better than dirty code

but what exactly is clean code?

There is no single universal definition

But you know it when you see it

and the experts clearly agree

elegant efficient readable maintainable beautiful simple direct

clear intent shareable expected understandable modifiable testable correct

reusable clear resilient meaningful minimal focused crisp

straightforward accessible real-world good strategic no surprises performant

software craftsmanship

“Clean code always looks like it was written by someone who cares”

Michael Feathers

the primal conundrum

speed: go fast (and make a mess) vs. or

quality: go slow (and miss the deadline)

the primal conundrum

But it’s the wrong paradigm!

“The only way to make the deadline—the only way to go fast— is to keep the code as clean as possible at all times.”

Robert C. Martin

we need sometools and

techniqueslike a broom, or a towel, or something…

training

obviously…

but conferences aren’t enough

internal training, online courses, offline courses, code reviews,pair programming, code retreats, mentoring, user groups, etc.

keep it dry

don’t repeat yourself!

ever

SOLID principles• single responsibility principle• do just one thing, have one reason to changeSRP• open closed principle• open for extension, closed for changeOCP• liskov substitution principle• all implementations should behave consistentlyLSP• interface segregation principle• implement only necessary abstractionsISP• dependency inversion principle• externalize dependencies and rely on abstractionsDIP

dependency inversion

all the principles are important,but the most effective is probably dependency inversion

focus on managing dependencies

avoid calling constructorsprefer abstractions (interfaces and base classes)use dependency injectionuse inversion of control (IOC) containers

meaningful names

meaningful names express intentexpressive code is easy to share and understand

do not underestimate their importance, don’t be too lazy

meaningful names should:

not be ambiguous or abbreviatednot require comments or notationbe pronounceable and searchable and consistent

be ubiquitous

form the backbone for effective communication in a team

functions

functions should do just one thingand they should do it well

keep functions short

short means ≈ 5 lines of code

refactoring“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

Martin Fowler

a discipline, part of being professionalrefactorings have names, like design patternsuse the right toolsavoid “big refactorings” – a refactoring is small

common refactorings

renamemoveextract variableextract methodextract parameterextract interfaceinline variable

many more on http://www.refactoring.com/catalog/

side effects

avoid side effects

side effects are unexpected state changesside effects hide dependencies

emergent design

a simple design keeps code clean and facilitates emergent design by following these four rules:

runs all the testscontains no duplicationexpresses the intent of the programmerminimizes the number of classes and methods

Kent Beck

just the tip of the iceberg

comments are smellythe law of demeter, a.k.a. only talk to friendsprefer exceptions over error statesuse unit tests and test-driven development (TDD)the boy scout rulelearn to work with third-party and legacy codedesign patterns always on your minduse clean architecture and architectural patternsand the list goes on…

inconclusion

you guessed it, we’re almost done

summary

clean code is about our values

summary

clean code is about being professional

summary

clean code is about using the right tools and techniques

summary

clean code is about being passionate and happy

additional resources

Clean Code: A Handbook of Agile Software Craftsmanship

by Robert C. Martin

http://blog.cleancoder.com/http://martinfowler.com/http://www.meetup.com/Clean-Code-Alliance/

Questions

Noam Kfir | @NoamKfir | noamkfir@sela.co.il