The document discusses the importance of clean code, defining its characteristics and benefits while identifying common pitfalls of bad code. It provides guidelines for maintaining readability, understandability, and changeability in code, as well as highlighting refactoring techniques to improve code quality. Additionally, it emphasizes the collaborative responsibility of development teams to ensure code cleanliness and presents the Boy Scout Rule as a guiding principle.

1. CLEAN CODE
SWARAJ PATIL

2. AGENDA
• Does Clean Code matters ?
• What is Clean Code ?
• What is Bad code?
• What can we do to keep Code Clean ?
• Who is accountable to keep it Clean ?
• What are benefits of Clean Code?
• Demo

3. In which house do you like to live ??

4. Did you experience this?
• Call from office at mid night or when you are on leave
• Cancel your leave due to office work
• Frustrating emails from customer (Fix at one place – break other place)
• Long debugging sessions
• Same type of work (same module)
• Blaming other developer for bad code

6. Excuses for not writing clean code
• Tight deadlines
• Client is demanding
• Changing Requirements
• Legacy code
• Managers don’t allow to write high quality code
• Not worth to spend time on this
• Practically it’s not possible

7. What is Clean Code ??
• Easy to Read
• Easy to Understand
• Easy to Change
• Easy to Test

8. Why easy to read ??
• Developers spend more time in reading code than writing
• Other Developers need to use / modify code written by you
• New members to team should quickly find out required code
• Quickly understand English than code

9. How to make it easy to read ??
• Meaningful names
• Choose name from problem / solution domain
• Don’t worry about length of function name
• Class name - Noun , Method Name – Verb
• Don’t hesitate rename
• Write code that read like story
• Consistency in naming things

10. Why easy to understand ??
• Anyone should able to work on any feature
• Developers in team are changing
• Less knowledge transfer required
• We need work life balance

11. How to make it easy to understand ??
• Meaningful names
• Better abstraction
• Simple solution that will work
• Avoid over engineering

12. Why easy to change ??
• Change is constant – business is changing,
customers are changing, End User Changes
• Customer are not sure about their
requirement until they use it
• Customer need changes in quick time to
sustain in market
• Technology is changing

13. Two values of software
• The primary value of software is that it is soft (maintainable, scalable, and
readable).
• The secondary value of software is that it solves your customer’s current
problem without any issues

14. How to make it easy to change ??
• Loose coupling
• High Cohesion
• Remove unwanted complexity
• Remove duplication

15. Design Smell - Rigidity
• Hard to change
• The tendency of software to be difficult to change, even in simple ways

16. Design Smell - Fragility
• Easy to break
• The tendency of software to break at many places when single change is
made

17. Design Smell - Immobility
• Hard to reuse
• It is hard to break system into small components that can be reuse in other
system

18. Design Smell - Viscosity
• Hard to maintain good design
• The software in which doing things wrong is easier than doing things right

19. What can we do ??
• Design Patterns
• SOLID Principles
• Fancy architecture and
frameworks
• Start with Simple Solution

20. Four rules of simple design
• Passes the tests
• Reveals intention
• No duplication
• Fewest elements

21. Code Smells
• Structure in code which is easy to
spot on
• Which indication of improvement
required in code

22. Refactoring
• Code refactoring is the process of restructuring existing code without
changing its external behaviour
• Refactoring is continuous process.
• Refactor - To eliminate Code Smell
• Refactor – When it is not easy to add new feature

23. Test Driven Development
• Remove fear
• Fast Feedback
• Automated Unit Testing
• Better Design
• CI and CD

24. Two Hat Theory

25. Duplicate Code
Symptoms / Problems
• Same block of code present at
more than one place
• Conceptual duplication
• Changes required at multiple
places
Refactoring
• Extract method
• Extract Superclass
• Extract Class
• Form Template Method
• Use of generics
• Pull up fields / methods

26. Long Method
Symptoms / Problems
• More than 4 lines
• Difficult to read and understand
• Not reusable
Refactoring
• Extract Method
• Decompose Conditional
• Replace Method with
Method Object
• Remove Temporary Variables

27. Temporary Variable
Symptoms / Problems
• Temporary variable are created in
method to store or return value
• Single exit point design lead to
use of temp variable
• Need backtracking / debugging to
find out value of temporary
variables
Refactoring
• Remove temp with query
• Multiple exit point

28. Nested Conditionals
Symptoms / Problems
• Nested if and else statements
• Difficult to understand
• Code get more complex as
additional changes /
enhancement required
Refactoring
• Replace conditional with
guard clause
• Decompose conditional
• Remove unwanted
conditional statement
• Remove Temp Variable

29. Large Class
Symptoms / Problems
• Class cluttered with too many
fields and methods
• Class Length more than screen
size
• Too many instance of class
created
• Not reusable
Refactoring
• Extract Class
• Extract Subclass
• Move Method

30. Getters and Setters
Symptoms / Problems
• Get and Set methods (Public
properties) to access private fields
• Breaks encapsulation
• Introduce coupling
Refactoring
• Remove Getter and Setter
methods
• Move method
• Encapsulate data and
behaviour together

31. Feature Envy
Symptoms / Problems
• Method is using more fields from
another class
• Introduce coupling
Refactoring
• Extract Method
• Move Method
• Pull up
• Remove Getter and Setter

32. Switch Statements
Symptoms / Problems
• Problem with switch statement is
– they are duplicated at different
places.
• Method with switch statement
does more than one thing
Refactoring
• Replace type code with sub
classes
• Replace type code with State
/ Strategy
• Replace conditional with
polymorphism

33. Long Parameter List
Symptoms / Problems
• More than 3 parameters are not
acceptable
• It is hard to understand and hard
use as list keep growing
• Introduce coupling
Refactoring
• Replace Parameter with
Method Call
• Preserve Whole Object
• Introduce Parameter Object

34. Flag Parameter
Symptoms / Problems
• Method does two thing when you
have flag (Boolean) parameter
• It lead to long parameter list
Refactoring
• Extract Method

35. Comments
Symptoms / Problems
• We write comments to explain
what code is doing
• Comments become out of sync
with code over time period
• Acts as Deodorants
Refactoring
• Extract Method
• Rename Method

36. Dead Code
Symptoms / Problems
• Unused code
• Commented code
• It adds unwanted noise to code
Refactoring
• Remove unused items
• Delete Commented code
• Version Control

37. Lazy Class
Symptoms / Problems
• If a class doesn't do enough to earn
your attention, it should be deleted.
• Understanding and maintaining
classes always costs time and money.
• Unwanted complexity
Refactoring
• Inline Class
• Collapse Hierarchy
• Avoid Data Class

38. Magic Numbers
Symptoms / Problems
• Hard coded numbers, strings used
in code
• We can't reason about specific
number / string
• Changes required at multiple
places
• It’s duplication
Refactoring
• Use constants with
meaningful names
• Access values from
configuration files

39. Primitive Obsession
Symptoms / Problems
• Use of primitive types instead of
small objects e.g. Money, Date
Range, Phone Number, Address
etc.
• Duplication of code occurs when
some behaviour required for such
types
Refactoring
• Replace data value with
object
• Introduce Parameter Object
• Replace array with object

40. Speculative Generality
Symptoms / Problems
• Code is written by assuming
future requirement
• YAGNI ( You Aren’t Gonna Need It)
• Added unwanted complexity
• Premature Abstraction
Refactoring
• Remove unused abstract class,
interfece
• Inline Class - Unnecessary
delegation of functionality to
other class
• Inline Method
• Remove Parameter
• Delete unused fields

41. Collaborative efforts required

42. The Boy Scout Rule
• Leave the campground cleaner than you found it.
• If we all checked-in our code a little cleaner than when we checked it out
• This is helpful to keep code clean for long term
• It’s collective responsibility to keep code clean

43. Pair Programming
• Keep you focused
• Learning from each other
• Code quality
• Collective code ownership
• Efficient code reviews
• Team building (avoid blame culture)

44. Benefits
• Low maintenance cost
• Rapid development
• Reduce technical debt
• Agility
• Happy customer and management
• Developer satisfaction of writing good code

45. "Always code as if the guy who
ends up maintaining your code
will be a violent psychopath who
knows where you live." - Martin
Golding

47. Want to learn more ??