This ppt is based on the book "Clean Code" written by Robert C Martin. It's a wonderful book and cover all the mistakes that we do while writing bad code. I am sharing few good practices shared in the book, hope you will like it

1. Clean Code
“Master programmers think of
systems as stories to be told rather
than programs to be written”
By -: Uday Pratap Singh

2. Agenda
 What is clean code
 What makes us write bad code
 Talk about meaningful names
 How to make functions readable &
understandable

3. Clean Code
A lot like painting a picture

4. What is clean code
 Is it Readable?
 Is it Maintainable?
 Is it Reusable?
 Is it Testable?

5. What is clean code
 Should be Readable like a well written
book.
 Should be crisp. Contain only what is
necessary.
 Provides one way rather than many ways
of doing one thing.
 Does one thing well. Each class, function
exposes single minded attitude.

6. What is clean code
 Easier for other people to enhance it.
 Smaller is better.
 Contains no duplication
 Close to expectations. No surprises

7. What is clean code
“You need to write that minimizes the
time it would take someone else to
understand it – even if that someone
else is you – Dustin Boswell and
Trevor Foucher”

8. Do you know?
Time spent reading versus writing
is well over 10:1
if you want your code to be easy to write, make it easy to read

9. Total cost of owning a Mess

10. What makes us write bad code?
 Were you trying to go fast?
 Tired of working on this program and
wanted it to be over.
 Looked at the backlog
 To clean it up later.
“We forget later equals never”

11. Why does good code rots?
Requirements change
Tight schedule
Stupid Managers
...

12. Suppose if patient demands to stop hand
washing because it’s taking too much time.
Doctor will refuse to do that because he knows
the risk involved in it.
Fault is Ours. We are Unprofessional.

13. Meaningful Names
Choosing meaningful name takes time
but saves more than it takes

14. Rules
 Name should tell you why it exists, what it
does, and how it is used
e.g: int elapsedTimeInDays
 Make meaningful distinctions.
e.g: customerInfo is indistinguishable
from customer
 Use Pronounceable names.
e.g: genymdhms

15. Rules Cont...
 No magic String or magic numbers.
 Use searchable names
e.g; MAX_CLASSES_PER_STUDENT is
easily searchable rather than 7.
 Pick one word per concept.
eg: it’s confusing to have fetch, retrieve,
and get as equivalent methods for
different classes.

16. Rules Cont...
 You also don’t need to prefix member
variables.
e.g; personName variable in Person class
 Class names should have noun or noun
phrase names like Customer, Account,
AddressParser etc.
 Method name should start with the verb.
e.g; postPayment, save, delete etc.

17. Rules Cont...
 Use problem domain names.
 Variable holding collection should be
plural.
e.g; persons, employees
 If a variable is expected to have a
default value, then assign it at the time
of declaration

18. Rules Cont...
 Don’t be cute.
 Choose clarity over entertainment value.
 Use kill rather than whack.
 Say what you mean. Mean what you say.

19. Functions
Should be easy to read and understand
which communicates its intent

20. Rules
 Small should be smaller.
 Avoid more the 10 lines.
Do not write more than 120 character in
one line ( Line should be visible at one
glance)
 Should be properly indented.
 It should not be more than 2.
 Blocks in if, else or loops should be only 1
line. Probably that 1 line should be a method
call.

21. Rules Cont..
 Do one thing.
 Should do it well.
 Should do it only.
 Avoid multiple return statements.
 Long descriptive name is better than
long comment.
 Well defined parameters (with
descriptive names) are better than a
map as parameter.

22. Rules Cont...
 Step Down Rule – Code read from top to
bottom.
 Function Arguments
 More than three (polyadic) requires very
special justification—and then shouldn’t be
used anyway.
 Passing flag argument is a terrible
practice. It loudly proclaims that
the function does more than one
thing.

23. Rules Cont...
 Has no side effects.
 checkPassword method should only check
whether password is correct or not, it should
not initialize the user session. If we want to
initialize the session then method name should
be checkPasswordAndInitializeSession.
 Function should either change the state of
object or it should return some information
about the object. Doing both often leads to
confusion.

24. Rules Cont...
 Prefer exception to returning error codes.
 Extract body of try catch blocks into
method to increase the readability and
structure of the code.
 DRY (Do not Repeat Yourself).

25. “Leave the campground cleaner
than you found it”

26. Thanks...