Ich bin auf diesen Twitter Thread gestoßen, und fand den Inhalt und die Darstellung so gut und eingängig, dass dieser Beitrag entstehen musste 😉
Abgesehen von SOLID Prinzipien muss für mich Code vor allem lesbar (einfach erfassbar) sein.
Ein Bild sagt mehr als 1000 Worte.
Anstelle mehrerer else if oder elsif Blöcke, oder einem größeren switch/case, kann es sinnvoll sein, ein Array zu verwenden. Bestenfalls ist das Key-Value-Mapping jeweils einzeilig und so leichter zu erfassen. Aber: bitte beim Array Lookup keine Magie verwenden, am besten einfach $output = $map[$input] ?? null verwenden, und ggf. ein if($output === null) throw new LogicException()` anfügen.
Früh aussteigen. Ein oft genutzter Ansatz ist, eine Methode an genau einer Stelle zu verlassen. Dies führt aber zu tiefen Verschachtelungen, die oft nicht leicht zu überblicken sind.
Besser ist es, alle (oder die meisten) Vorbedingungen am Anfang abzuprüfen, und bei Verstößen direkt auszusteigen. Das ist offensichtlich, und lenkt den Fokus auf die eigentliche Aufgabe.
Code sollte lesbar sein. Manche sagen, man solle Code lesen können wie ein Buch, ich behaupte, man sollte ihn lesen können wie eine Tageszeitung: schmale Zeilen erfordern weniger Augenbewegung. Um dies zu erreichen, sollte der Code nicht irgendwo umgebrochen werden, sondern an Stellen, an denen es auch Sinn macht: Am Anfang einer Parameterliste oder eines Arrays, oder bei verketteten Aufrufen.
Extra Tipp: Verständigt euch im Team darauf, ob ein Umbruch durchgezogen werden muss (also z.B. wenn einmal umgebrochen, muss jeder Parameter in eine eigene Zeile), oder nicht
