Clean Code

Öffnen Sie in Python eine Datei, die nicht existiert, wirft open() einen FileNotFoundError, der aus Ihrer Funktion heraus nach oben durchläuft. Tun Sie dasselbe in Go, gibt os.ReadFile einen error-Wert neben einem nil-Byte-Slice zurück. Derselbe Fehlschlag, zwei völlig unterschiedliche Code-Formen darum herum. Der Unterschied ist nicht kosmetisch. Er entscheidet, ob ein Aufrufer den Fehlschlag versehentlich ignorieren kann, und ob der Compiler es merkt, wenn er es tut. Was machen Exceptions und Error Values wirklich unterschiedlich? Eine Exception ist Kontrollfluss, der springt. Etwas schlägt fehl, die Funktion wirft, und die Ausführung verlässt den aktuellen Call-Stack und landet im nächsten passenden catch- oder except-Block, egal wie viele Ebenen weiter oben das ist. Die Signatur der Funktion gibt keinen Hinweis darauf, dass das passieren kann. loadConfig(path: string): Config in TypeScript sieht genau wie eine Funktion aus, die nicht fehlschlagen kann – bis sie bei einer fehlenden Datei eine Exception wirft. ...

Eine Klasse, die einen Nutzer in der Datenbank speichert, ihm eine Willkommens-E-Mail schickt und eine Quittung formatiert, ist eine Änderung davon entfernt, zwei Funktionen zu zerstören, mit denen sie nichts zu tun hat. Fassen Sie das E-Mail-Template an, riskieren Sie den Schreibzugriff auf die Datenbank. Fassen Sie das Quittungslayout an, riskieren Sie die E-Mail. SOLID ist der Sammelbegriff für fünf Regeln gegen genau diese Art von Verknotung, jede aus einem anderen Blickwinkel. Sie teilen eine Idee: Eine Klasse soll nur einen Grund haben, sich zu ändern, und der Rest des Codes soll davon abhängen, was etwas zu tun verspricht, nicht davon, wie es das tut. ...

Hier ist eine Klasse, die Sie ohne eine laufende Datenbank und einen funktionierenden SMTP-Server nicht unit-testen können: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService baut sich seine eigenen SqlOrderRepository- und SmtpEmailSender-Instanzen mit new, Connection-String und allem. Jeder Test, der PlaceOrder berührt, braucht eine echte Orders-Datenbank und einen echten Mailserver, sonst scheitert er, bevor Ihre Assertion überhaupt läuft. Die Logik, die Sie testen wollen, sind zwei Zeilen: die Bestellung speichern, die Bestätigung senden. Sie ist an zwei konkrete Klassen geschweißt, die Sie nicht austauschen können. ...

Sie öffnen eine Funktion, um einen Ein-Zeilen-Bug zu beheben, und vierzig Minuten später verfolgen Sie immer noch, welcher Zweig welche Variable setzt. Drei voneinander unabhängige Aufgaben sind in einem einzigen Block zusammengeschweißt, und keine von ihnen hat einen Namen. Sie ziehen an einem Faden und können nicht sagen, welche anderen sich mitbewegen. Das ist Spaghetti-Code, und der Name hat nichts mit Einrückung oder Namensstil zu tun. Er beschreibt den Kontrollfluss: Die Ausführung springt zwischen Bedingungen hin und her, so wie ein Nudelstrang jeden anderen in der Schüssel kreuzt, und einem einzigen Pfad bis zum Ende zu folgen bedeutet, vier Ebenen von if gleichzeitig im Kopf zu behalten. ...