Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clean code for beginners

1768d238acf404dadd501ba424d65bfd?s=47 dknx01
September 05, 2018

Clean code for beginners

A short overview of clean code

1768d238acf404dadd501ba424d65bfd?s=128

dknx01

September 05, 2018
Tweet

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