{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n\n### Suggestion\n\n### Code Style\n- Benenne Attribute/Parameter konsistent zu den Vorgaben: In der Aufgabenbeschreibung heisst es `zipCode`, in deinem Code ist es teils `zipcode`/`getZipCode()`; das ist nicht falsch, kann aber in Tests/Autocheckern Probleme machen, wenn exakt erwartete Namen verwendet werden.\n- In `format()` ist die temporäre Variable `formatted` nicht nötig; du kannst den String direkt zurückgeben (macht den Code etwas schlanker/lesbarer).\n- Deine Validierungs-`if`-Kaskade im Konstruktor enthält viele sehr ähnliche `throw new IllegalArgumentException()`-Zweige; das lässt sich lesbarer gestalten (z.B. durch frühzeitige Checks oder eine gemeinsame Validierungsmethode), ohne das Verhalten zu ändern.\n- In den Settern ist die `else throw ...`-Schreibweise etwas schwerer zu lesen; ein einheitlicher Stil (z.B. erst invalid prüfen und sofort werfen, danach setzen) wirkt klarer.\n- Optional für bessere Fehlersuche: `IllegalArgumentException` mit einer Nachricht werfen, damit klar ist, welche Invariante verletzt wurde.\n\n\n# Exercise: timespan\n\n### Correctness\n- Der Konstruktor setzt `hours`/`minutes` ohne Preconditions: Damit können negative Zeitspannen entstehen, wodurch `totalMinutes() ≥ 0` verletzt werden kann.\n- `add(int hours, int minutes)` erlaubt negative Parameter und kann dadurch die Zeitspanne verkürzen; das verletzt `totalMinutes ≥ old(totalMinutes)` und auch die Forderung, dafür Preconditions mit `IllegalArgumentException` zu definieren.\n- `getMinutes()` kann außerhalb von `0..59` liegen (z.B. nach `add(0, 90)`), damit ist die geforderte Invariante `0 ≤ getMinutes ≤ 59` nicht eingehalten.\n- Wenn im Konstruktor z.B. `minutes = 90` übergeben wird, ist die Minuten-Normalisierung ebenfalls nicht sichergestellt (auch ohne `add`-Aufruf).\n\n### Suggestion\n- Überlege dir, welche Eingaben im Konstruktor erlaubt sein sollen, damit `totalMinutes()` nie negativ werden kann, und wie du bei unerlaubten Eingaben konsequent eine `IllegalArgumentException` auslöst.\n- Für `add(...)`: Formuliere eine Bedingung, die garantiert, dass die Zeitspanne nicht kleiner werden kann als vorher (insbesondere bei negativen Stunden/Minuten), und prüfe diese Bedingung vor dem Aktualisieren der Felder.\n- Damit `getMinutes()` immer zwischen 0 und 59 bleibt, brauchst du nach dem Addieren eine Umrechnung/Normalisierung der Minuten in Stunden + Restminuten (insbesondere, wenn `minutes` über 59 wächst).\n- Falls du die Normalisierung an einer Stelle implementierst, achte darauf, dass sie sowohl nach dem Konstruktor als auch nach `add(...)` greift (z.B. indem du Logik wiederverwendest).\n\n### Code Style\n- Invariante-Logik (Validierung/Normalisierung) ist aktuell gar nicht vorhanden; sobald du sie einbaust, versuche Doppelcode zu vermeiden (z.B. gleiche Checks/Normalisierung nicht zweimal getrennt pflegen).\n- Eine `toString()`-Methode fehlt im Attempt; sie ist zwar nicht explizit gefordert, kann aber beim Testen/Debuggen hilfreich sein.\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- `turnNextRoomBright`: Du schaltest nur einzelne Lampen ein/auf 1.0, nämlich jene, die gerade `off` sind oder nicht 1.0 haben. Gefordert ist aber: **in diesem ersten “nicht fertigen” Raum alle Lampen** einschalten und auf **1.0** setzen.\n- `turnNextRoomBright`: Du verwendest ein `return` zum Abbrechen, obwohl in der Aufgabenstellung explizit steht, möglichst ohne *early return* zu lösen.\n- `nightMode`: In Hallway und in jedem Bedroom soll **genau eine** (beliebige) Lampe eingeschaltet und auf 0.3 gesetzt werden. Bei dir können es **zwei verschiedene Lampen** sein, weil du für `turnOn()` und `setBrightness(0.3)` jeweils getrennt einen zufälligen Index ziehst.\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir, wie du pro Raum zuerst feststellen kannst, ob der Raum “nicht fertig hell” ist (mindestens eine Lampe ist aus oder nicht auf 1.0). Wenn ja, dann in einem zweiten Schritt **über alle Lampen dieses Raums** laufen und sie alle auf `on` und `1.0` setzen. Damit brauchst du auch kein `return`.\n- `turnNextRoomBright` ohne early return: Du kannst mit einer bool-Variable arbeiten, die merkt, ob du den Raum schon gefunden/angepasst hast, und dann die äußeren Schleifen entsprechend “neutral” weiterlaufen lassen (oder Schleifenbedingungen entsprechend aufbauen), ohne `break/continue/return`.\n- `nightMode`: Zieh pro Raum **einmal** den zufälligen Lampenindex (oder die Lampenreferenz) und verwende dann **dieselbe** Lampe sowohl für `turnOn()` als auch für `setBrightness(0.3)`.\n\n### Code Style\n- In `turnAllOff()` ist `Room[] room = getRooms();` unnötig verwirrend benannt (Singular) und du greifst trotzdem wieder über `getRooms()[i]` zu; konsistenter wäre: einmal holen und dann auch verwenden.\n- Mehrfaches wiederholtes Auslesen von `rooms[i].getLamps()` innerhalb derselben Schleife (z.B. in `saveEnergy`) macht den Code unnötig schwer lesbar; speichere das Lampen-Array einmal in eine Variable.\n- Du nutzt `Random.nextDouble(0.5, 1.0)` / `nextInt(0, ...)`: je nach Java-Version ist das evtl. nicht verfügbar. Falls euer Kurs auf einer älteren Version läuft, könnte das zu Kompilierfehlern führen; dann besser eine Variante wählen, die in eurer Umgebung sicher unterstützt 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"
}
}