The document discusses principles of clean code, beginning with definitions of clean code from various authors. It outlines key principles like the single responsibility principle and open/closed principle. It then covers sections on meaningful naming, functions, and classes. For functions, it recommends they be small, do one thing, avoid flag arguments, and have no side effects. For classes, it advocates for small size, encapsulation, high cohesion and low coupling following the single responsibility principle.

1. Clean Code
by Robert C. Martin

2. Agenda
Introduction
Meaningful names
Functions
Classes

3. Agenda
Introduction
Meaningful names
Functions
Classes

4. What is a Clean Code ?
Bjarne Stroustrup, inventor of C++ and author of The C++
Programming Language.
“Clean code does one thing well”

5. What is a Clean Code ?
“Big” Dave Thomas, founder of OTI, godfather of the
Eclipse strategy.
“Clean code can be read, and
enhanced by a developer other
than its original author.”

6. What is a Clean Code ?
Robert C. Matrin, the author.
“Less ‘type and erases’ ”

7. How to measure Code Cleanliness ?

8. Key principles
Single Responsibility Principle (SRP)
⚪A class should have one responsibility over a single part of the
functionality, and that responsibility should be entirely
encapsulated by the class.
Open/Closed Principle (OCP)
⚪Software entities (classes, modules, functions, etc.) should be
open for extension, but closed for modification.

9. Agenda
Introduction
Meaningful names
Functions
Classes

10. Meaningful Name
Use Intention-Revealing Names
⚪If a name requires a comment, then the name does not reveal
its intent

11. Meaningful Name
Use Intention-Revealing Names

12. Meaningful Name
Use Pronounceable Names

13. Meaningful Name
Use Searchable Names
⚪Use a search-friendly name.

14. Meaningful Name
Pick One Word per Concept
⚪Pick one word for one abstract concept and stick with it.
⚪‘fetch’, ‘retrieve’, and ‘get’
Don’t Pun
⚪Avoid using the same word for two purposes.
⚪‘Add’

15. Meaningful Name
Class Names
⚪Noun or noun phrase names.
⚪ ‘Customer’, ‘WikiPage’, ‘Account’, and ‘AddressParser’
⚪Avoid words like ‘Manager’, ‘Processor’, ‘Data’, or ‘Info’
Method Names
⚪Verb or verb phrases.
⚪ ‘postPayment’, ‘deletePage’, or ‘save’
⚪Static factory methods with names that describe the
arguments.

16. Meaningful Name (Final Words)
Choosing good name requires
⚪Good descriptive skills.
⚪A shared cultural background.
It’s very grateful to change names (for the better)

17. Agenda
Introduction
Meaningful names
Functions
Classes

18. Functions
Small!
⚪Around 2-4 lines!
Blocks and Indenting
⚪Any ‘if’ or ‘while’ condition should be a method call.
⚪Indentation level shouldn’t be more than 2.

19. Functions
Do One Thing
⚪And do it well!

20. Functions
Do One Thing(cont.)
⚪TO notation
One level of abstraction.
⚪‘PathParser.render(pagePath);’
⚪‘pageData.getHtml()’
⚪‘pageString.append("n")’
A lot of implementation
details (high level)
Less details
(lower level)

21. Functions
Reading Code from Top to Bottom: The Stepdown Rule
High level of
abstraction
Lower level of
abstraction

22. Functions
Function Arguments
⚪Ideal number of arguments is ZERO (niladic).
⚪Next comes one (monadic), followed closely by two (dyadic).
⚪Three arguments (triadic) should be avoided.
Common Monadic Forms
⚪A function should be for
◾Asking a question ‘boolean fileExists(“MyFile”)’
◾Transforming input into something else and returning it
‘InputStream fileOpen(“MyFile”)’
⚪A function should return something

23. Functions
Flag arguments
⚪Passing a boolean into a function is a truly terrible practice.
⚪‘render(true)’ ??!!
⚪‘render(boolean isSuite)’ should be
‘renderForSuite()’ and ‘renderForSingleTest()’.
Output Arguments
⚪‘public void appendFooter(StringBuffer report)’
should be :
◾‘report.appendFooter();’
⚪If your function must change the state of something, have it
change the state of its owning object.

24. Functions
Have No Side Effects
Side effect!

25. Functions
Prefer Exceptions to Returning Error Codes
One entry and one exit points
⚪A function should have one ‘return’.
⚪Avoid ‘break’, and ‘continue’.

26. Agenda
Introduction
Meaningful names
Functions
Classes

27. Class
Encapsulation
Classes Should Be Small!
⚪Small means the number of responsibilities.
⚪The name of a class should describe what responsibilities it
fulfills.
⚪A class that you spend some time to name it is a big class.

28. Class
Encapsulation
Classes Should Be Small!
⚪Small means the number of responsibilities.
⚪The name of a class should describe what responsibilities it
fulfills.
⚪A class that you spend some time to name it is a big class.
The Single Responsibility Principle
⚪Classes should have one responsibility—one reason to change.
⚪This helps the developer to find, where to write code

29. Class
Cohesion
⚪The more instance variables a method manipulates the more
cohesive.
⚪A class in which each variable is used by each method is
maximally cohesive.
⚪High cohesion is always better.
Coupling
⚪Happens when a class rely or depend(partly) on another class.
⚪Less coupling is always better.

30. Class
Cohesion and Coupling

31. To be continued..