Writing Clean PHP

Using Object Calisthenics and identifying Code Smells to re-factor code

Transcript

1. WRITING CLEAN PHP USING OBJECT CALISTHENICS AND IDENTIFYING CODE SMELLS TO RE-FACTOR CODE JORDAN HOFF
2. ABOUT ME • Software Engineer • Twitter: jordanthoff • Github / GitLab: jhoff
3. GOALS OF THIS TALK Improve code • Readability • Maintainability • Reusability • Testability
4. DISCLAIMER These are not rules, they're suggestions. Use them or don’t. I don’t really care. Don’t take them too literally or you’ll end up right where you started.
5. OBJECT CALISTHENICS Object Oriented Programming Exercising
6. BRIEF INTRO • Original concepts introduced in "ThoughtWorks Anthology" by Jeff Bay in 2008 • Adapted for PHP by Rafael Dohms and Guilherme Blanco in 2012 • "Your code sucks, let's fix it” • https://www.slideshare.net/rdohms/bettercode- phpbenelux212alternate • Laracasts series "Simple Rules for Simpler Code" • https://laracasts.com/series/simple-rules-for-simpler-code
7. OBJECT CALISTHENICS RULES Only one level of indentation per method Do not use “else” keyword Wrap primitive types and strings First class collections Only one object operator per line Don’t abbreviate Keep classes small No classes with more than two instance variables No getter/setters
8. #1 DON’T ABBREVIATE BUT ALSO, NOT TOO VERBOSE Use short words that you would speak: Id, Info, Url, etc.
9. #2 ONLY ONE ARROW PER LINE GIVE YOUR CODE ROOM TO BREATHE return $this->project->deployments()->where('status', 'Available')->orderBy('updated_at', 'DESC')->get(); return $this->project->deployments() ->where('status', 'Available') ->orderBy('updated_at', 'DESC') ->get();
10. #2 ONLY ONE ARROW PER LINE GIVE YOUR CODE ROOM TO BREATHE
11. #3 ONLY ONE LEVEL OF INDENTATION PER METHOD
12. #3 ONLY ONE LEVEL OF INDENTATION PER METHOD
13. #3 ONLY ONE LEVEL OF INDENTATION PER METHOD
14. #4 DO NOT USE “ELSE”
15. #4 DO NOT USE “ELSE”
16. OBJECT CALISTHENICS RULES Only one level of indentation per method Do not use “else” keyword Wrap primitive types and strings First class collections Only one object operator per line Don’t abbreviate Keep classes small No classes with more than two instance variables No getter/setters
17. CODE SMELLS Code Bad ( maybe )
18. BRIEF INTRO • Originally popularized by Kent Beck in the late 90s and then later by Martin Fowler in "Refactoring" • https://martinfowler.com/books/refactoring.html • Sandi Metz - Get a whiff of this • https://speakerdeck.com/skmetz/get-a-whiff-of- this
19. CODE SMELLS Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy Data Clumps Primitive Obsession Switch Statements Parallel Inheritance Hierarchies Lazy Class Speculative Generality Temporary Field Message Chains Middle Man Inappropriate Intimacy Alternative Classes with Different Interfaces Incomplete Library Class Data Class Refused Bequest Comments
20. #1 DUPLICATED CODE Exact code in same class => Re-factor to a method Exact code in sibling class => Re-factor to a method in the parent class Similar code => Re-factor to a method with parameters Duplicate code in different classes => Use a trait Use the Rule of Three!
21. #2 LONG METHODS Shorter methods are more maintainable. Longer methods are harder to understand. Shorter methods mean more methods, specifically single use methods. Single use methods are NOT a bad thing! Makes your code more readable!
22. #3 LARGE CLASSES AKA GOD CLASSES Give a class too much responsibility and it can quickly become too large. Look for large numbers of properties and public methods. Refactoring opportunity: Look for name chunks. Frontend classes can benefit from domain classes to simplify. Lots of protected or private methods is generally ok.
23. #4 DATA CLUMPS Groups of variables that are passed around together. Create a new object to keep them together. Simplifies parameter lists. Examples:
24. #5 SPECULATIVE GENERALITY Writing a method or class that isn’t needed yet. Don’t do it. Waste of time. You can’t see in the future! Increases complexity, you have to work around it. If by chance you actually use it later, it’s unlikely that you did it right.
25. #6 LAZY CLASS Similar to Speculative Generality without any effort. A class that is stubbed out but not completed. Sometimes the result of a lot of refactoring and it just doesn't do much anymore. Get rid of it if it’s not worth having!
26. #7 DATA CLASS Similar to a Lazy Class. Object with properties, getters and setters only. Not worth the extra work involved to interact with. A class needs to actually do something with it's data. Get rid of it!
27. #8 COMMENTS Comments are not a bad thing. They should be used. But sometimes they are overused or used to mask another code smell. Example: In-line comment that explains the line below it. "Comments are often used as a deodorant.” Re-write so that a human can actually understand it.
28. CODE SMELLS Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy Data Clumps Primitive Obsession Switch Statements Parallel Inheritance Hierarchies Lazy Class Speculative Generality Temporary Field Message Chains Middle Man Inappropriate Intimacy Alternative Classes with Different Interfaces Incomplete Library Class Data Class Refused Bequest Comments
29. TOOLS TO HELP ENFORCE • PHP Code Sniffer - Detect and correct violations in coding standards. • https://github.com/squizlabs/PHP_CodeSniffer • PHP Mess Detector - Object Calisthenics and then some • https://phpmd.org/ • PHP Copy / Paste Detector • https://github.com/sebastianbergmann/phpcpd
30. THANK YOU