Maintainable + Extensible = Clean ... yes, Code!
1 like450 views
Antonio Perić-Mažar emphasizes the importance of clean code in software development, highlighting characteristics of bad code and guidelines for writing maintainable, extensible, and readable code. He discusses practices such as meaningful naming, adherence to coding standards, and utilizing design patterns to improve code quality. The presentation stresses the long-term benefits of investing in good code, including reduced technical debt and increased efficiency in development.
Maintainable + Extensible = Clean ... yes, Code!
- 2. @antonioperic About me • Antonio Perić-Mažar, mag. ing. comp. • CEO, Co-Founder @ Locastic • Co-Founder @ Shift Conference • Software developer, Symfony2 • Open Source Contributor • SFUGCRO • w: www.locastic.com • m: antonio@locastic.com • t: @antonioperic
- 3. @antonioperic Locastic • We help clients create amazing web and mobile apps (since 2011) • design and development agency • mobile development • web development • UX/UI • Training and Consulting • Shift Conference, Symfony Croatia • www.locastic.com • t: @locastic
- 5. @antonioperic Questions? • Who thinks he is producing good code? • What is bad code? • What is good code? • Do you know how to measure code quality?
- 10. @antonioperic
- 11. @antonioperic
- 12. @antonioperic
- 14. @antonioperic
- 15. @antonioperic Code Smell!!! (Bad Code) • Use globals • Anything hardcoded (url, ip, etc) • Long classes or methods • Deep structures • Long and bad names • Lack of formatting • Lack of standard
- 16. @antonioperic Code Smell!!! (Bad Code) • Overuse of public static • Too many parameters • Weird order of parameters • GOD Object (he can do everything and he knows everything) • No input validation • No comments
- 17. @antonioperic Code Smell!!! (Bad Code) • Takes 1-2 sentences to explain • Copy-pasted - repetitive code • Never used inheritance, interface or composition • not readable • not testable
- 18. @antonioperic Code Smell!!! (Bad Code) • hard to understand • hard to maintain • gives a headache • you don’t won’t to work on/with it
- 19. @antonioperic
- 22. @antonioperic
- 23. @antonioperic But why we still doing it… • We are lazy • Short deadlines • Bad decisions • Fast - good - cheap • We are always the best developer ever :)
- 28. @antonioperic
- 29. @antonioperic Language is evolving • Frameworks (Symfony <3) • Package managers (composer) • Standards • PHP7
- 32. @antonioperic
- 33. @antonioperic Clean code • Code that doesn’t exist • KISS • DRY • SOLID • Don’t reinvent the wheel • Design Patterns • Testable -> Tested
- 34. @antonioperic Clean code • Flexible • Maintainable • Easy to refactor • Readable
- 36. @antonioperic
- 37. @antonioperic Why we should care… • Someone else will use that code • You will use that code • Bad code does a lot of things but none well • You don’t write code just to be there • Maintaining should be easy • Good code save money and time
- 38. @antonioperic
- 40. @antonioperic
- 42. @antonioperic #1 Naming matters • Don’t abbreviate • $string->b = false; • $string->bold = false; • Make code readable • Meaningful names • Improves readability • Good code should be talking to you • You should read it like a book, whitespace is important
- 43. @antonioperic #1 Naming matters • Two world words variable name • $data, $data2 • $total, $total2, $total3
- 46. @antonioperic #1 Naming matters • Good name should explain • why it exist • what it does • how to use it • If you need comment for explain it, it is bad name • Class should use a noun, method a verb
- 47. @antonioperic #2 Code standard • Don’t mix styles in project, use whitespace • Easier to navigate inside project • Less time for boarding new developer • PHP-FIG • Stick with PSR • PSR-0 autoloading • PSR-1 basing code style • PSR-2 detailed coding style
- 49. @antonioperic #3 Use only one level of indentation per method • {{{ }}} try to avoid this • force single responsibility • small, simple, easier to understand • our mind model is important • separate logic blocks and complex level of indentation into methods
- 50. @antonioperic #4 Don’t use else • reduce code complexity • early returns • use Exceptions • it reduce complex of our mind model • method should not do more then one thing • don’t use intermediate variable • use polymorphism, switch is signal for polymorphism • don’t abuse polymorphism
- 52. @antonioperic #5 Keep your classes/methods small • easier to test • do one thing, and do one thing well • all functions should return something and avoid returning NULL • keep methods small (max. 20 lines of code) • avoid side-effects • avoid global state
- 53. @antonioperic #6 Use Exceptions • Use them • Make sure to catch them • Specify the nature of the error • throw new InvalidArgumentException(); • Don’t use special error codes
- 54. @antonioperic #7 Design patterns • use them, they give you solution for some well known problems
- 56. @antonioperic #8 Use SPL • Datastructures • SplDoublyLinkedList — The SplDoublyLinkedList class • SplStack — The SplStack class • SplQueue — The SplQueue class • SplHeap — The SplHeap class • SplMaxHeap — The SplMaxHeap class • SplMinHeap — The SplMinHeap class • SplPriorityQueue — The SplPriorityQueue class • SplFixedArray — The SplFixedArray class • SplObjectStorage — The SplObjectStorage class
- 57. @antonioperic #8 Use SPL • Iterators • AppendIterator — The AppendIterator class • ArrayIterator — The ArrayIterator class • CachingIterator — The CachingIterator class • CallbackFilterIterator — The CallbackFilterIterator class • DirectoryIterator — The DirectoryIterator class • EmptyIterator — The EmptyIterator class • FilesystemIterator — The FilesystemIterator class • FilterIterator — The FilterIterator class • GlobIterator — The GlobIterator class • InfiniteIterator — The InfiniteIterator class • …
- 58. @antonioperic #8 Use SPL • Interfaces • Countable — The Countable interface • OuterIterator — The OuterIterator interface • RecursiveIterator — The RecursiveIterator interface • SeekableIterator — The SeekableIterator
- 59. @antonioperic #8 Use SPL • Exceptions • BadFunctionCallException — The BadFunctionCallException class • BadMethodCallException — The BadMethodCallException class • DomainException — The DomainException class • InvalidArgumentException — The InvalidArgumentException class • LengthException — The LengthException class • LogicException — The LogicException class • OutOfBoundsException — The OutOfBoundsException • OutOfRangeException — The OutOfRangeException • OverflowException — The OverflowException • RangeException — The RangeException • RuntimeException — The RuntimeException • UnderflowException — The UnderflowException • UnexpectedValueException — The UnexpectedValueException class
- 60. @antonioperic #9 Law of demeter (LoD) • Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. • Each unit should only talk to its friends; don't talk to strangers. • Only talk to your immediate friends • Help you build code that is easier to test
- 63. @antonioperic #9 Law of demeter (LoD) • Benefits: • Keep object instant ion simple • Easier to mock objects • Simplify dependency graph
- 64. @antonioperic #10 Comments • Good comments • Bad comments • PHPDoc • Don’t use comments for tracking history of changes
- 65. @antonioperic #11 Use tools • PHPCS • PHP-CS-Fixer • pDepend (performs static code analysis) • PHPLOC (A tool for quickly measuring the size of a PHP project) • SensioLabs Insight • phpmd (mess detector) • PHPCPD (copy paste detector) • PHPDCP (dead code detector) • learn more about your IDE (PHPStorm is amazing tool)
- 66. @antonioperic #12 improve yourself • read a lot of code • http://www.livecoding.tv/ • work in pairs • do open source - you will get a lot of free reviews from amazing developers • show your code to other developers • go to conferences • be responsive for your code
- 70. @antonioperic Conclusion • Clean code is: • structured • simple • consistent • Use boy scout rule • Do small steps • There is no silver bullet only hard work
- 71. @antonioperic References • https://cleancoders.com/ • Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin • Dotting Your I’s and Crossing Your T7s, Juliette Reinders Folmer, IPC Sprint 2015 • Your code sucks, let's fix it - By Rafael Dohms • Clean Code, Tobias Schlitt, WebSummerCamp 2016 • Google Tech Talks, Clean Code • https://www.youtube.com/watch?v=HZJxjlvBbVA, Clean Code, David Donahue • Plenty of other talks at Youtube