Clean code for beginners

A short overview of clean code

Transcript

1. Clean Code A short version of: Let’s code professional
2. Erik Witthauer PHP developer for > 10 years aka: dknx01 Twitter: @ewnx01 speakerdeck: speakerdeck.com/dknx01 currently working at: FTI
3. Introduction • Good developers, but still learning (your whole life) • Writing code is easy, but what about ◦ easy maintenance ◦ readability ◦ documentation (self or external ) ◦ easy extending or changing (refactoring!?) ◦ remembering what was last week/month/year in this software => We need this for professional software (and other stuff)
4. Clean Code Solution:
5. Meaningful names
6. Meaningful names • names are everything and everywhere (variables, methods, classes, folders, namespace ...) • intension revealing • should answer all big questions (why it exists, what it does, how to use it) ◦ what is this and do I know this in the next lines ◦ do other understand it immediately ◦ no confusion ◦ double interpretation
7. Meaningful names • comments should be avoided -> rethink the name • short is not always good, long and meaningful is better • avoid unnecessary information ◦ e.g. the type: $registrationsArray = []; public function (array $fooArr) {...} ◦ namespace • avoid (own) abbreviations • stay in the domain language (problem, solution, maybe business) • searchable and pronounceable names
8. Meaningful names • classes: only single nouns or noun phrases (Customer) • methods: verbs or verb phrases (processCustomerAddress) • (mostly) hide providers: sendViaGmail -> sendEmail
9. Methods / Functions
10. Methods / Functions • small!!!!!!!!!! or even smaller!!!!! • one things only, but his good (incl. error handling) • Never use “And” or “Or” in naming -> doing too much • top to bottom • one abstraction layer • switch: no big blocks -> call function • if: own function, if possible
11. Methods / Functions • descriptive names • few arguments: 0 == ideal, 1 == perfect, 2 == ok, 3 == avoid it, >3 == very bad and explanation needed (what about an object?) • avoid null arguments • no side effects: (hidden calls or changes) • only one visible output (avoid references, one type) • command query separation (do something or answer something) • use exceptions
12. Classes
13. Classes • should be small • Single Responsibility Principle • less cohesion • organize for change: changes are not a high risk
14. Comments
15. Comments • necessary evil at best • less is more • no excuse for bad writing/coding (complex, unreadable ...) • are NOT documentation • be clear • no redundancy, misleading, out dated • avoid inline (hard to find), class/method docblock should be enough
16. Formatting
17. Formatting • use standards if exists (e.g. PSR2) • blank line between functions • blanks line for structuring (not to much) • must increase readability
18. Object and Data structures
19. Object and Data structures
20. Object and Data structures • abstraction • keep private stuff private • avoid (too many) public properties • use accessor methods (getter, setter, adder, remover ...) • expose behaviour, hide data
21. Error handling
22. Error handling • use exceptions • avoid “magic” numbers • provide descriptive error message (and context) • exceptions for the callers need, not generics • provide help for the normal way • no return null; • checking arguments (type hinting or check value )
23. Boundaries
24. Boundaries • wrapper for external/3rd party classes • use interfaces, bridges, (abstract) adapters • clean boundaries everywhere • do not rely to much on code out of your control
25. Unit testing
26. Unit testing • define what a unit is in the team • small, but many: one test one thing • meaningful • mock/stub anything outside the unit • no external services • keep them clean and understandable: readability, readability, readability • brocken test are fine, but must be fixed (there are valid reason for the broken things)
27. Unit testing • F.I.R.S.T. ◦ Fast (frequent running, not long-running) ◦ Independent (no running order, single run) ◦ Repeatable (in any environment, at any time) ◦ Self-Validating (boolean output) ◦ Timely (write before production)
28. Unit testing • Not business/use cases, they test the implementation ◦ -> Testing pyramide • forget a case, write a new test • test domain specific language are fine • tests are not documentation, but helping understanding • TDD? • write them
29. • Robert C. Martin: Clean Code • Blogs: https://martinfowler. com • conference talks at youtube Further reading
30. Questions? Comments? Discussions? Don’t beat the presenter, he could be right (?) Slide: https://speakerdeck.com/dknx01/clean-code-for-beginners
31. Thank you