Clean code
- 1. Clean code Nguyen Quang Duc
- 2. Contents ▪ What is clean code, bad code ▪ Why it matters ▪ Meaningful names and formatting ▪ Functions ▪ Comments
- 3. Clean code vs bad code Clean code ▪ Easy to understand ▪ Easy to maintain ▪ Easy to extend Bad code ▪ Mysterious ▪ Fragile ▪ Dangerous
- 4. Why do we write bad code ▪ Tight schedule ▪ Tired of project ▪ Get working now, clean up later (or never) ▪ Everybody does it!
- 5. Why should we write clean code ▪ We spent most of our time reading rather than writing ▪ Bad code will cost you: ▪ Time ▪ Money ▪ Relationship ▪ Talent
- 6. The boy scout rule ▪ Leave the campground cleaner than you found it.
- 7. How do we write clean code
- 8. Meaningful names ▪ Use Intention-Revealing Names ▪ Don’t be afraid of longer names, the name should say everything about it. ▪ Avoid abbreviation This is bad: protected $d; This is good: protected $elapsedTimeInDays; protected $daysSinceCreation; protected $daysSinceModification; protected $fileAgeInDays;
- 9. ▪ Use pronounceable name This is bad: public $genymdhms; public $modymdhms; This is good: public $generationTimestamp; public $modificationTimestamp; ▪ Use one word per concept Be consistent. For example, don’t use get and fetch to do the same thing in different classes ▪ Use verbs for function names and nouns for classes and attributes
- 10. Formatting ▪ Follow a single coding style ▪ There is no obvious "best" style. Just being consistent. ▪ Each line should be composed of a single expression. ▪ Each block should present a single thought. ▪ Blocks should be separated with a single, empty line. ▪ A line of the code should not exceed 80 characters ▪ Our eyes are more comfortable when reading tall and narrow columns of text ▪ Use indentation and alignment to improve the readability
- 11. Functions ▪ The smaller the better ▪ A function should only do one thing ▪ No nested control structure ▪ Less arguments are better ▪ No side effects ▪ Avoid output arguments ▪ Don’t repeat yourself
- 12. Hard to read Easy to understand
- 13. Comments ▪ Don’t comment bad code, rewrite it ▪ If code is readable you don’t need comments ▪ Explain your intention in comments ▪ Warn of consequences in comments ▪ Emphasis important points in comments ▪ Always have you PHPDoc comments ▪ Noise comments are bad ▪ Never leave code commented
- 14. ▪ The best comment is the code itself For example: // check if customer can buy products if ($customer->isActive() && $customer->getAge() > 65) is not as good as: if ($customer->canBuyProducts()) ▪ Avoid obvious comments ▪ Other kind of useful comments Legal comments, e.g. // Copyright (c) 2014 Magento Inc. Informative comments, e.g. // Returns an instance of a Customer object Purpose-explaining comments, e.g. return 1; // it is default value Warning comments, e.g. // very slow query, don’t use if you don’t need to TODO comments, e.g. // @TODO rewrite this query
- 15. Reference ▪ Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin ▪ http://www.slideshare.net/mariosa ngiorgio/clean-code-and-code- smells ▪ http://www.slideshare.net/JandV/c lean-code-summary ▪ http://www.slideshare.net/josedasi lva/phplx