{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor setzt Du die Felder **vor** der Validierung; bei ungültigen Argumenten wird zwar eine `IllegalArgumentException` geworfen, aber das Objekt ist bis dahin bereits mit ungültigen Werten befüllt worden (Invarianten werden also nicht “von Anfang an” sauber eingehalten).\n- In den Settern weist Du den neuen Wert ebenfalls **vor** der Prüfung zu; wenn die Prüfung fehlschlägt, bleibt das Objekt schon auf einem ungültigen Zustand stehen.\n- Die Fehlermeldung im Konstruktor passt nicht zu allen Fehlerfällen: Du wirfst immer `\"Street cannot be empty\"`, auch wenn z.B. `zipCode` oder `number` ungültig sind.\n\n### Suggestion\n- Prüfe die Eingaben erst und weise die Felder erst dann zu, wenn sie gültig sind (oder nutze innerhalb des Konstruktors die Setter, sofern diese korrekt validieren, ohne vorher zuzuweisen).\n- Achte darauf, dass ein fehlgeschlagener Setter-Aufruf den alten (gültigen) Zustand beibehält; ein einfacher Weg ist, erst zu validieren und dann zu setzen.\n- Verwende passendere Fehlermeldungen (oder zumindest eine generische, die alle möglichen ungültigen Argumente abdeckt), damit klar ist, was genau falsch war.\n\n### Code Style\n- Parameter-Namen wie `bahnhofweg`, `basel` oder `i` sind verwirrend; benenne sie neutral nach ihrer Bedeutung (`street`, `city`, `number`, `zipCode`).\n- Die Validierungslogik ist teils dupliziert (Konstruktor vs. Setter). Das macht Wartung schwieriger; versuche die Prüfungen an einer Stelle zu bündeln, damit Änderungen nicht mehrfach gemacht werden müssen.\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Precondition im Konstruktor ist zu schwach: Aktuell erlaubst du z.B. `hours = -1` und `minutes = 120`, weil die Summe nicht negativ ist – aus Client-Sicht sind aber negative Stunden/Minuten nicht erlaubt (und sollen per `IllegalArgumentException` abgefangen werden).\n- Die Precondition in `add` ist ebenfalls zu schwach: Auch hier wäre z.B. `add(-1, 120)` möglich, ohne dass verkürzt wird, obwohl negative Werte laut Aufgabenstellung nicht zugelassen sind.\n- `getMinutes()` kann negative Werte liefern, wenn jemand z.B. mit `hours = 0` und `minutes = -1` startet (oder entsprechend addiert), weil dann `totalMinutes % 60` negativ wird; das verletzt die Invariante `0 ≤ getMinutes ≤ 59`.\n\n### Suggestion\n- Überlege dir die Preconditions so, dass sie direkt die Eingabeparameter betreffen (nicht nur die resultierende Summe). Welche Kombinationen aus `hours` und `minutes` sollen grundsätzlich verboten sein, unabhängig davon, ob die Summe zufällig ≥ 0 bleibt?\n- Für `add`: Die Invariante “nur verlängern” bedeutet “neuer totalMinutes ≥ alter totalMinutes”, aber zusätzlich sollen negative Argumente nicht akzeptiert werden. Prüfe daher beides: (1) keine negativen Parameter, (2) die Veränderung darf nicht negativ sein.\n- Damit `getMinutes()` garantiert zwischen 0 und 59 liegt, muss der Zustand so abgesichert sein, dass `totalMinutes` nie negativ werden kann (auch nicht durch “kompensierende” negative/positive Eingaben). Dann ist `% 60` automatisch im gewünschten Bereich.\n\n### Code Style\n- Die Fehlermeldung im Konstruktor ist irreführend: “empty” passt hier nicht (Ints können nicht “empty” sein) und die Message sollte möglichst genau den eigentlichen Verstoß beschreiben (z.B. negative Parameter vs. negative Gesamtdauer).\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 `turnNextRoomBright()` schaltest du nur die einzelne Lampe ein/auf 1.0, die die Bedingung erfüllt; gefordert ist aber: **in diesem Raum alle Lampen** einschalten und auf **1.0** setzen.\n- In `turnNextRoomBright()` wird nach dem Finden des ersten passenden Raums nicht verhindert, dass in demselben Raum weitere Lampen ebenfalls geprüft/evtl. geändert werden; das ist zwar nicht das Hauptproblem, aber es passt nicht sauber zur Idee „ersten Raum finden, dann diesen Raum komplett setzen, danach fertig“.\n- In `saveEnergy()` initialisierst du `minPowerConsumption` mit `25.0`. Wenn ein Raum nur Lampen mit höherem Verbrauch hätte, bleibt `cheapestLamp` `null` und danach würdest du `cheapestLamp.turnOn()` aufrufen (würde crashen). Die Aufgabe verlangt eine allgemeine Lösung für beliebige Räume/Lampen.\n\n### Suggestion\n- Für `turnNextRoomBright()`: Überlege dir eine zweistufige Logik: (1) Erkennen, ob ein Raum „nicht komplett hell“ ist, (2) wenn ja, dann in einem separaten Schritt **alle** Lampen dieses Raums auf `on` und `brightness=1.0` setzen und danach keine weiteren Räume mehr verändern.\n- Für `saveEnergy()`: Wähle den Startwert für das Minimum so, dass er garantiert über jedem echten Lampenverbrauch liegt, oder initialisiere das Minimum/„cheapest“-Lampe mit der **ersten Lampe im Raum** und vergleiche dann ab der zweiten weiter.\n\n### Code Style\n- In `turnNextRoomBright()` und `findHallway()` nutzt du zusätzliche Flags (`roomFound`, `hallwayFound`), um ein „break“ zu vermeiden. Das ist ok, aber du könntest die Blockstruktur oft klarer machen, wenn du zuerst suchst (Index/Referenz merken) und danach in einem zweiten Block die Aktion ausführst.\n- `Random r = new Random();` wird in `randomize()` und `nightMode()` jeweils neu erstellt. Üblicher ist es, ein `Random` einmal als Feld zu halten (oder zumindest nicht in jeder Methode neu), damit der Code ruhiger und besser testbar ist.\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"
}
}