• 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)
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
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
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
== 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
• 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
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 )
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)
◦ Independent (no running order, single run) ◦ Repeatable (in any environment, at any time) ◦ Self-Validating (boolean output) ◦ Timely (write before production)
◦ -> 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