Clean code

1,342 views

Published on

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

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,342
On SlideShare
0
From Embeds
0
Number of Embeds
155
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Clean code

  1. 1. Clean Code “Master programmers think of systems as stories to be told rather than programs to be written” By -: Uday Pratap Singh
  2. 2. Agenda What is clean code What makes us write bad code Talk about meaningful names How to make functions readable & understandable
  3. 3. Clean CodeA lot like painting a picture
  4. 4. What is clean code Is it Readable? Is it Maintainable? Is it Reusable? Is it Testable?
  5. 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. 6. What is clean code Easier for other people to enhance it. Smaller is better. Contains no duplication Close to expectations. No surprises
  7. 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. 8. Do you know? Time spent reading versus writing is well over 10:1if you want your code to be easy to write, make it easy to read
  9. 9. Total cost of owning a Mess
  10. 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. 11. Why does good code rots? Requirements change Tight schedule Stupid Managers ...
  12. 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. 13. Meaningful NamesChoosing meaningful name takes time but saves more than it takes
  14. 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. 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. 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. 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. 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. 19. FunctionsShould be easy to read and understand which communicates its intent
  20. 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. 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. 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. 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. 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. 25. “Leave the campground cleaner than you found it”
  26. 26. Thanks...

×