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

Clean code for beginners

dknx01
September 05, 2018

Clean code for beginners

A short overview of clean code

dknx01

September 05, 2018
Tweet

More Decks by dknx01

Other Decks in Programming

Transcript

  1. Clean Code
    A short version of: Let’s code professional

    View full-size slide

  2. Erik Witthauer
    PHP developer for > 10 years
    aka: dknx01
    Twitter: @ewnx01
    speakerdeck: speakerdeck.com/dknx01
    currently working at: FTI

    View full-size slide

  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)

    View full-size slide

  4. Clean Code
    Solution:

    View full-size slide

  5. Meaningful names

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  8. Meaningful names
    ● classes: only single nouns or noun phrases (Customer)
    ● methods: verbs or verb phrases (processCustomerAddress)
    ● (mostly) hide providers: sendViaGmail -> sendEmail

    View full-size slide

  9. Methods / Functions

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  12. Classes
    ● should be small
    ● Single Responsibility Principle
    ● less cohesion
    ● organize for change: changes are not a high risk

    View full-size slide

  13. 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

    View full-size slide

  14. Formatting
    ● use standards if exists (e.g. PSR2)
    ● blank line between functions
    ● blanks line for structuring (not to much)
    ● must increase readability

    View full-size slide

  15. Object and Data structures

    View full-size slide

  16. Object and Data structures

    View full-size slide

  17. 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

    View full-size slide

  18. Error handling

    View full-size slide

  19. 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 )

    View full-size slide

  20. 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

    View full-size slide

  21. Unit testing

    View full-size slide

  22. 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)

    View full-size slide

  23. 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)

    View full-size slide

  24. 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

    View full-size slide

  25. ● Robert C. Martin:
    Clean Code
    ● Blogs:
    https://martinfowler.
    com
    ● conference talks at
    youtube
    Further reading

    View full-size slide

  26. Questions? Comments? Discussions?
    Don’t beat the presenter, he could be right (?)
    Slide: https://speakerdeck.com/dknx01/clean-code-for-beginners

    View full-size slide