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

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

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) 

Clean Code Solution: 

Meaningful names 

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 

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 

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

Methods / Functions 

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 

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 

Classes 

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

Comments 

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 

Formatting 

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

Object and Data structures 

Object and Data structures 

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 

Error handling 

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 ) 

Boundaries 

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 

Unit testing 

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) 

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) 

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 

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

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

Thank you