{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor setzt du die Felder **vor** der Validierung. Wenn ungültige Werte übergeben werden, wird zwar eine `IllegalArgumentException` geworfen, aber das Objekt wurde dabei bereits (kurzzeitig) in einen ungültigen Zustand versetzt – das verletzt die Idee der Invarianten/sauberen Kapselung im Konstruktor.\n\n### Suggestion\n- Prüfe die Argumente im Konstruktor **bevor** du `this.street`, `this.number`, `this.zipCode`, `this.city` zuweist, oder nutze im Konstruktor die Setter (die validieren ja schon), damit der Zustand erst bei gültigen Daten gesetzt wird.\n\n### Code Style\n- Duplizierst Validierungslogik: Im Konstruktor prüfst du alles nochmal, obwohl die Setter bereits passende Checks haben. Das macht Wartung fehleranfälliger (Regeln müssen an mehreren Stellen konsistent gehalten werden).\n- Kleine Konsistenz: `private int zipCode;` hat einen doppelten Abstand; außerdem sind Getter methodisch gemischt (`getCity()` steht zwischen anderen Gettern), was die Lesbarkeit etwas senkt.\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Precondition für den Konstruktor ist zu schwach: Mit `hours=0, minutes=-1` ist `hours*60+minutes < 0` zwar negativ (gut), aber mit `hours=1, minutes=-30` wird `totalMinutes` positiv, obwohl ein negativer Minutenanteil aus Client-Sicht nicht als sinnvolle Eingabe für `hours`/`minutes` gilt (deine Prüfung lässt das durch).\n- In `add(...)` prüfst du nur, dass `totalMinutes` nicht kleiner wird, aber du erlaubst dadurch z.B. `add(0, -10)` solange die Gesamtminuten nicht sinken (oder bei bestimmten Kombinationen sogar doch “formal” die Bedingung erfüllen). Damit sind negative Parameter nicht zuverlässig ausgeschlossen, obwohl die Aufgabe “sinnvolle Preconditions” und IllegalArgumentException verlangt.\n- Die Bedingung in `add(...)` ist zudem logisch problematisch, weil du `this.totalMinutes()` auf beiden Seiten verwendest; das schützt nicht sauber vor Verkürzung, sondern hängt davon ab, wie du den Ausdruck formulierst (und ist anfällig für Rechen-/Overflow-Effekte).\n- `totalMinutes()` kann bei sehr großen Werten durch `hours * 60` überlaufen; dann können deine `< 0` bzw. “nicht verkürzen”-Checks falsche Ergebnisse liefern und Invarianten umgehen.\n\n### Suggestion\n- Überlege im Konstruktor, welche Eingaben für `hours` und `minutes` aus Sicht des Clients “zulässig” sein sollen: Willst du negative Minuten überhaupt akzeptieren, auch wenn die Summe nicht negativ ist? Formuliere die Precondition entsprechend direkt auf den Parametern und/oder auf einer eindeutig berechneten Gesamtminuten-Zahl.\n- Für `add(...)`: Formuliere die Precondition so, dass eine Verkürzung unabhängig von der aktuellen `totalMinutes()`-Berechnung ausgeschlossen ist (Stichwort: “delta”/Zuwachs muss ≥ 0). Zusätzlich solltest du negative Parameter als solche abfangen, statt nur indirekt über einen Vergleich.\n- Um Overflow-Probleme zu vermeiden, rechne für Checks mit einem größeren Zahlenbereich (z.B. Zwischenergebnis in einem größeren Typ) oder strukturiere die Prüfung so, dass `hours*60` nicht unkontrolliert überläuft.\n\n### Code Style\n- In `getHours()`/`getMinutes()` rechnest du jeweils erneut über `totalMinutes()`. Das ist zwar funktional, aber unnötig indirekt und kann bei Overflow/Inkonsistenzen schwerer zu debuggen sein; konsistenter wäre, die normalisierten Felder direkt zu verwenden (wenn du sie ohnehin normalisierst).\n- Die `IllegalArgumentException()` ohne Nachricht macht Fehlersuche für Client-Code schwerer; eine kurze Message, welche Precondition verletzt wurde, wäre hilfreicher.\n\n\n# Exercise: asteroids\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: smarthome\n\n### Correctness\n- In `randomize()` verwendest du `random.nextDouble(0.5, 1.0)`: Das setzt Java 17+ voraus; falls die Übung mit einer älteren Java-Version (z.B. 11) getestet wird, kompiliert das nicht.\n- In `findHallway()` gibst du `null` zurück, obwohl laut Aufgabenstellung davon ausgegangen wird, dass genau eine Hallway existiert (und `nightMode()` danach direkt damit arbeitet). Das kann zu einem Laufzeitfehler führen, wenn aus irgendeinem Grund nichts gefunden wird.\n- In `nightMode()` schaltest du zwar in Hallway und Bedrooms je eine Lampe ein, aber du wählst immer stumpf `getLamps()[0]`. Falls ein Raum keine Lampen hätte, würde das crashen (die Aufgabenstellung sagt nicht explizit, dass jeder Raum mindestens eine Lampe hat).\n\n### Suggestion\n- Falls du nicht sicher bist, welche Java-Version verwendet wird: Überlege dir eine Variante, um eine Zufallshelligkeit zwischen 0.5 und 1.0 zu erzeugen, die ohne die neuere `nextDouble(min,max)`-Überladung auskommt.\n- Bei `findHallway()`: Da „genau eine Hallway existiert“ garantiert ist, sollte dein Kontrollfluss so aufgebaut sein, dass am Ende auch wirklich ein `Room` geliefert wird und du den „unerreichbaren“ Fall entsprechend behandelst, ohne dass Folgecode mit `null` arbeiten muss.\n- Für `nightMode()`: Überlege dir, wie du „eine beliebige Lampe“ pro Raum einschalten kannst, aber dabei trotzdem sicherstellst, dass du nur dann auf Index 0 zugreifst, wenn es diesen auch gibt (z.B. erst prüfen, ob es Lampen gibt, oder die Auswahl anders strukturieren).\n\n### Code Style\n- Du nutzt `var zufaulligerraum` mit einem nichtssagenden/fehleranfälligen Namen und gemischter Sprache; besser wäre ein klarer englischer oder deutscher Name (z.B. `randomRoomIndex`) und korrekte Schreibweise.\n- `private Random random = new Random();` sollte `final` sein, wenn du ihn nicht neu zuweist (`private final Random random = new Random();`).\n- In `saveEnergy()` rufst du in der inneren Schleife mehrfach `room.getLamps()` auf; das Array einmal in eine lokale Variable zu legen macht den Code lesbarer.\n- Auskommentierter Code (`isRoomFindetStromgering`) sollte entfernt werden, wenn er nicht mehr gebraucht wird.\n\n\n# Exercise: bosses\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}