{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- In `getCity()` wirfst du eine `IllegalArgumentException`, falls `city` leer ist. Laut Aufgabe sollen Konstruktor und **Setter** bei ungültigen Argumenten werfen; ein Getter sollte nicht plötzlich wegen eines ungültigen internen Zustands eine Exception werfen.\n- `getCity()` prüft nur `city.isEmpty()`, aber nicht `city == null`. Wenn `city` jemals `null` wäre (z.B. durch zukünftige Änderungen), würde der Getter eine `NullPointerException` werfen statt (wie gefordert) die Invariante über Konstruktor/Setter sicherzustellen.\n\n### Suggestion\n- Überlege, wo die Invarianten am besten durchgesetzt werden: Ziel ist, dass ein `Address`-Objekt nach außen hin gar nie in einen ungültigen Zustand kommen kann. Wenn du das konsequent über Konstruktor und Setter sicherstellst, brauchst du im Getter keine Validierung mehr.\n- Falls du trotzdem defensiv prüfen willst, denke daran, dass Strings auch `null` sein können – aber frage dich, ob diese Prüfung überhaupt in einen Getter gehört.\n\n### Code Style\n- Du hast dieselben Validierungen mehrfach (z.B. für `street`, `city`, `number`, `zipCode`) in Konstruktor und Settern. Das lässt sich oft sauberer lösen, indem du Validierungslogik zentralisierst (z.B. in privaten Hilfsmethoden), damit du sie nur einmal pflegen musst.\n- Die Fehlermeldung bei `zipCode` ist inhaltlich etwas ungenau („muss positiv sein“), obwohl du eigentlich „vierstellig“ prüfst; sprechendere Messages helfen beim Debuggen.\n\n\n# Exercise: timespan\n\n### Correctness\n- In `add(...)` wird die Invariante **`totalMinutes` ≥ old(`totalMinutes`)** nicht korrekt als Precondition geprüft: `if(totalMinutes() >= this.minutes)` vergleicht die aktuelle Gesamtminuten-Zahl mit den aktuellen Minuten (0–59) und sagt nichts darüber aus, ob der Aufruf die Zeitspanne verkürzt. Dadurch können verkürzende Aufrufe (z.B. negative Parameter) entweder fälschlich erlaubt/teilweise ignoriert werden oder die geforderte Exception-Logik wird nicht sauber erfüllt.\n- Die Precondition für `add(...)` soll eine Verkürzung verhindern und bei Verletzung eine `IllegalArgumentException` werfen. In deinem Code werden Aufrufe, die nach deiner Logik „nicht passen“, einfach nicht ausgeführt (durch das `if(...)`), aber es wird dann **keine** Exception geworfen.\n- Die Invariante **`totalMinutes` ≥ 0** ist nur dann garantiert, wenn intern nie ein Zustand entstehen kann, der negative Gesamtminuten ergibt. Durch die fehlerhafte Zusatzprüfung in `add(...)` ist das Verhalten nicht klar „durchgesetzt“ (z.B. ein Aufruf könnte ohne Exception „ignoriert“ werden statt sauber abgelehnt zu werden).\n\n### Suggestion\n- Überlege bei der Precondition von `add(...)`: Du musst prüfen, ob die **neue** Zeitspanne kleiner wäre als die **alte**. Das geht am einfachsten, indem du den „alten“ Wert (vor der Änderung) gedanklich mit dem „neuen“ Wert (alt + hinzugefügte Minuten) vergleichst.\n- Wenn ein `add(...)`-Aufruf die Regeln verletzt, sollte er nicht „still“ nichts tun, sondern klar scheitern. Überlege, an welcher Stelle du die `IllegalArgumentException` auslösen musst, statt nur ein `if` um das Addieren zu legen.\n- Schau dir nochmal an, welche Größe du in der zweiten Prüfung vergleichst: `this.minutes` ist nur der Minutenanteil (0–59 nach Normalisierung), aber die Invariante bezieht sich auf **totalMinutes** (Stunden+Minuten zusammen).\n\n### Code Style\n- Die Fehlermeldung `\"negativ\"` ist wenig aussagekräftig. Eine klarere Message hilft beim Debuggen (z.B. was genau negativ war bzw. welche Regel verletzt wurde).\n- `checkMinutes()` normalisiert nur, wenn `minutes >= 60`. Du könntest die Methode so benennen/strukturieren, dass klar ist, dass sie der Normalisierung dient (z.B. „normalize“ statt „check“), damit Leser sofort wissen, dass dort umgerechnet wird.\n- In `checkMinutes()` verwendest du einmal `this.minutes` und einmal `minutes` ohne `this` in `this.minutes = minutes - 60*divide;`. Funktional ist das hier zwar dasselbe, aber einheitliches `this.minutes` macht es leichter zu lesen.\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 machst letztlich alle Räume hell (und schaltest sie ein), statt nur den *ersten* Raum zu finden, der nicht komplett „an + Helligkeit 1.0“ ist, und nur diesen einen zu ändern.\n- `turnNextRoomBright`: Die innere Schleife `for (int i = 0; i < rooms.length; i++)` ist logisch falsch (sie iteriert über die Anzahl Räume, verändert aber Lampen im aktuellen Room mehrfach) und verändert das Ergebnis.\n- `saveEnergy`: Du schaltest/konfigurierst `minLamp` bereits während der Suche nach der minimalen Lampe und schaltest andere Lampen nur unter der Bedingung `if(lamp.isOn() && lamp != minLamp)` aus; dadurch können Lampen, die gerade aus sind, „überleben“, obwohl laut Aufgabe *alle anderen* aus sein müssen.\n- `findBedrooms`: Du initialisierst `bedrooms` innerhalb der Room-Schleife immer wieder als leeres Array und gibst innerhalb der Schleife sofort zurück; damit bekommst du nie „alle Bedrooms“, sondern höchstens ein (meist leeres) Ergebnis.\n- `findBedrooms`: Wenn ein Room kein Bedroom ist, gibst du am Ende der Methode `rooms` zurück (also alle Räume), was die Anforderung klar verletzt.\n- `nightMode`: Nicht implementiert, damit fehlt ein Teil der geforderten Funktionalität.\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir zuerst, wie du pro Raum prüfen kannst, ob *alle* Lampen `on` sind **und** `brightness == 1.0`. Erst wenn du einen Raum findest, bei dem das nicht zutrifft, solltest du genau diesen Raum komplett auf „an + 1.0“ setzen und danach nichts mehr an weiteren Räumen ändern.\n- `turnNextRoomBright`: Die zusätzliche Schleife mit `i < rooms.length` brauchst du für die Lampen in einem Raum nicht; versuch die Logik in „prüfen“ und „anwenden“ zu trennen, statt mehrfach über dasselbe Lampen-Array zu laufen.\n- `saveEnergy`: Finde zuerst wirklich nur die Lampe mit minimalem `powerConsumption` (ohne dabei schon Zustände zu verändern). In einem zweiten Durchlauf durch die Lampen des Raums kannst du dann: genau diese eine Lampe einschalten + auf 0.8 setzen, und *alle anderen* ausschalten (unabhängig davon, ob sie vorher an/aus waren).\n- `findBedrooms`: Lege das Ergebnis-Array einmal vor der Schleife an (maximal `rooms.length`) und fülle es während des Durchlaufens mit passenden Rooms (z.B. über einen separaten Index-Zähler). Wichtig: erst nach der Schleife zurückgeben.\n- `findBedrooms`: Gib bei „keine Bedrooms gefunden“ ein leeres (oder teilweise mit `null` gefülltes) Bedrooms-Array zurück, aber nicht `rooms`.\n- `nightMode`: Nutze `findHallway()` und `findBedrooms()` wirklich als Grundlage: zuerst alles ausschalten, dann in Hallway und jedem Bedroom genau *eine beliebige* Lampe einschalten und auf 0.3 setzen (z.B. jeweils die erste Lampe, falls vorhanden).\n\n### Code Style\n- In `randomize` erzeugst du in der Lampen-Schleife jedes Mal ein neues `Random`-Objekt; besser ein einziges `Random` pro Methode verwenden.\n- `findBedrooms` erstellt neue `Room`-Objekte (`new Room(...)`), obwohl du nur vorhandene Räume zurückgeben sollst; das macht den Code unnötig kompliziert und kann zu Verwirrung führen.\n- Unruhige/uneinheitliche Einrückung und Klammerplatzierung (z.B. in `saveEnergy`) erschwert das Lesen; formatiere Blöcke konsistent.\n- `Objects.equals(room.getName(), \"Hallway\")` ist ok, aber der zusätzliche Import nur dafür ist eher schwergewichtig; bei garantiert nicht-null `getName()` reicht auch ein direkter String-Vergleich über `\"Hallway\".equals(...)` (reduziert Null-Risiko ohne Extra-Import).\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"
}
}