{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- `getCity()` wirft eine `IllegalArgumentException`, wenn `city` leer ist; laut Aufgabe sollen **Konstruktor und Setter** bei ungültigen Argumenten werfen, nicht die Getter.\n\n### Suggestion\n- Überlege, wo die Invarianten wirklich „durchgesetzt“ werden müssen: Wenn du im Konstruktor und in `setCity(...)` bereits sicherstellst, dass `city` nie `null`/leer werden kann, dann sollte ein Getter normalerweise ohne Validierung einfach den aktuellen Wert zurückgeben.\n\n### Code Style\n- In `getCity()` steht Logik/Validierung, die in einem Getter unüblich ist; das macht die Klasse schwerer vorhersehbar (Lesemethode mit Seiteneffekt/Exception).\n\n\n# Exercise: timespan\n\n### Correctness\n- Im Konstruktor fehlen sinnvolle Preconditions für `hours`/`minutes`: Mit negativen Werten kann ein Objekt erzeugt werden, obwohl `totalMinutes ≥ 0` gefordert ist.\n- In `add(...)` wird die Negativprüfung falsch umgesetzt: `if (totalMinutes() < 0)` prüft den aktuellen Zustand, nicht die übergebenen Parameter bzw. den neuen Zustand nach dem Addieren.\n- Die Precondition „Zeitspanne kann nur verlängert werden“ (`totalMinutes` ≥ old(`totalMinutes`)) wird nicht korrekt geprüft: `if (totalMinutes() >= this.minutes)` vergleicht Minuten mit Gesamtminuten und hat nichts mit „alt vs. neu“ zu tun.\n- Wenn die „verlängern“-Bedingung nicht erfüllt ist, passiert in `add(...)` einfach nichts (silent fail). Laut Aufgabe sollen in solchen Fällen `IllegalArgumentException`s geworfen werden.\n- Die Invariante `0 ≤ getMinutes ≤ 59` wird nicht zuverlässig eingehalten: `checkMinutes()` korrigiert negative Minuten nicht so, dass am Ende garantiert `minutes` im Bereich 0..59 liegt (und kann dabei sogar Stunden in die falsche Richtung verändern).\n\n### Suggestion\n- Überlege dir bei jeder Operation: Welche Werte kommen von außen rein (Parameter) und welche Regel muss *vor* der Zustandsänderung gelten? Prüfe also die Parameter (und/oder den resultierenden neuen Gesamtwert), nicht den aktuellen `totalMinutes()`-Wert.\n- Für „nicht verkürzen“ brauchst du einen Vergleich „neuer Gesamtwert vs. alter Gesamtwert“. Rechne gedanklich einmal aus, wie du „alt“ und „neu“ in Minuten darstellen kannst, bevor du Felder veränderst.\n- Wenn eine Precondition verletzt ist, wirf immer eine `IllegalArgumentException` statt einfach nichts zu tun.\n- Für die Minuten-Normalisierung (0..59) hilft es, erst die gesamte Zeit in Minuten zu betrachten und dann wieder in Stunden+Minuten umzuwandeln, oder zumindest sicherzustellen, dass nach der Korrektur `minutes` wirklich im Zielbereich liegt.\n\n### Code Style\n- Die Methode `totalMinutes()` wird in `add()` aufgerufen, aber das Ergebnis wird ignoriert (`this.totalMinutes();`). Solche wirkungslosen Aufrufe entfernen oder sinnvoll nutzen.\n- Fehlermeldung `\"negativ\"` ist sehr knapp; nutze eine aussagekräftige Nachricht, die sagt, welche Bedingung verletzt wurde (z.B. negative Eingaben vs. Verkürzung).\n- `checkMinutes()` hat schwer nachvollziehbare Logik für negative Minuten und benutzt `divide` bei negativen Werten auf eine verwirrende Weise; versuche die Normalisierung klarer und symmetrischer zu formulieren (und vermeide doppelte/teilweise Korrekturen in getrennten `if`s, wenn sie sich beeinflussen).\n- Einheitliche Formatierung (Leerzeichen nach `if`, Einrückung) würde die Lesbarkeit verbessern.\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: bosses\n\n### Correctness\n\n### Suggestion\n\n### Code Style\n- `import java.util.ArrayList;` und die `ArrayList<Employee> bosses` in `findCommonSuperiorWith` sind für die Aufgabe nicht nötig; die Übung zielt explizit auf eine sequentielle Suche durch die Boss-Kette ab (ohne zusätzliche Datenstruktur).\n- In `findCommonSuperiorWith` verwendest du einmal `commonSuperior.equals(superior)` und sonst überall Referenzvergleiche (`==`). Da `Employee` kein eigenes `equals` überschreibt, ist das aktuell zwar effektiv dasselbe, aber es wirkt inkonsistent und kann später zu Verwirrung führen.\n- Die Variable `commonSuperior` wird erst als `this` initialisiert und dann als Laufvariable durch die Boss-Kette „weitergeschoben“ – der Name ist dabei etwas irreführend (weil es nicht *immer* der „common“ ist, sondern gerade der aktuelle Kandidat in der Kette).\n\n\n# Exercise: smarthome\n\n### Correctness\n- `nightMode`: Du schaltest in den Bedrooms nicht nur **eine** Lampe pro Bedroom ein, sondern (mindestens beim ersten gefundenen Bedroom) alle Lampen dieses Bedrooms.\n- `nightMode`: Durch die Flags `isOn`/`isOnB` schaltest du insgesamt nur **eine** Bedroom-Lampe im ganzen Haus ein, statt **je Bedroom** eine Lampe.\n- `nightMode`: Die Logik zum Ausschalten „aller anderen Lampen“ ist inkonsistent, weil du innerhalb einer tiefen Schleifenstruktur Lampen teils mehrfach an/aus schaltest; dadurch ist nicht sauber garantiert, dass am Ende genau die gewünschten Lampen an bleiben.\n- `findBedrooms`: Du gibst ein Array zurück, das **nicht** „auch grösser als nötig“ sein darf (du machst es exakt passend). Das ist zwar nicht verboten, aber du nutzt damit die erlaubte Freiheit nicht – relevant wird das, falls im Test explizit ein Array der Länge `rooms.length` erwartet wird.\n\n### Suggestion\n- `nightMode`: Denke in zwei klaren Phasen: (1) zuerst wirklich alle Lampen im ganzen Haus ausschalten, (2) danach gezielt pro gesuchtem Raum genau eine Lampe wieder einschalten und Helligkeit setzen.\n- `nightMode`: Für „je Bedroom eine Lampe“ brauchst du eine Entscheidung **pro Bedroom**, nicht ein globales `isOnB`. Überlege dir eine Schleife, die für jedes Bedroom separat „erste Lampe nehmen“ (oder irgendeine) macht.\n- `nightMode`: Vermeide es, während du noch durch „alle Räume und alle Lampen“ iterierst, nebenbei nochmal über Hallway/Bedrooms zu iterieren. Das macht Seiteneffekte schwer kontrollierbar. Besser: erst Räume bestimmen, dann handeln.\n- `findBedrooms`: Falls bei euch Tests wirklich tolerant sind, ist dein Ansatz ok. Wenn nicht: überlege, ob du wirklich ein Array der maximalen erlaubten Grösse zurückgeben willst und nur vorne befüllst (Rest `null`).\n\n### Code Style\n- In `randomize` erzeugst du in der inneren Lampen-Schleife jedes Mal ein neues `Random`-Objekt (`Random r = new Random();`). Nimm stattdessen ein einziges Random-Objekt pro Methode (oder sogar pro Klasse).\n- Mehrfacher Code zum „alle Lampen ausschalten“ kommt in mehreren Methoden vor (`turnAllOff`, `randomize`, indirekt in `nightMode`). Eine kleine Hilfsmethode würde die Blockstruktur deutlich sauberer machen.\n- Unnötige `null`-Checks auf `getLamps()` (gemäss Aufgaben-/Vorlagenstruktur sind Lampen-Arrays typischerweise nicht `null`). Das macht den Code länger und verschachtelter als nötig.\n- `import java.util.Objects;` wird nur für den String-Vergleich benutzt; bei Strings ist `room.getName().equals(\"Hallway\")` üblich (sofern `getName()` nicht `null` ist).\n",
"status" : "SUCCESS"
}
}