The document discusses clean code versus bad code. Clean code is easy to understand, maintain, and extend, while bad code is mysterious, fragile, and dangerous. The author provides tips for writing clean code such as using meaningful names, consistent formatting, small and focused functions, and comments that explain intent rather than state the obvious. The goal is to write code that is readable and maintainable over time.

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