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