{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- In `getCity()` wirfst du eine `IllegalArgumentException`, wenn `city` leer ist; laut Aufgabe sollen Konstruktor und **Setter** bei ungültigen Argumenten werfen, nicht die Getter. \n- In `getCity()` prüfst du außerdem nicht auf `null` (würde bei `city.isEmpty()` zu einer `NullPointerException` führen), was nicht zur geforderten Fehlermeldung per `IllegalArgumentException` passt.\n\n### Suggestion\n- Verschiebe die Validierung der `city`-Invariante vollständig in Konstruktor und `setCity(...)`, sodass ein einmal korrekt erzeugtes Objekt beim Lesen (Getter) keine Exceptions auslöst. \n- Überlege: Wenn alle Schreibwege (`constructor`/`setCity`) die Invariante garantieren, braucht ein Getter überhaupt noch Checks?\n\n### Code Style\n- Du wiederholst dieselben Validierungsblöcke in Konstruktor und Settern; langfristig wäre es sauberer, die Prüfung zentral zu halten (z.B. durch private Hilfsmethoden), damit du die Regeln nur an einer Stelle pflegen musst. \n- In den Fehlermeldungen für `zipCode` steht „muss positiv sein“, tatsächlich prüfst du aber „vierstellig“; eine präzisere Message würde besser zum Code passen.\n\n\n# Exercise: timespan\n\n### Correctness\n- Im Konstruktor fehlen sinnvolle Preconditions: Negative `hours`/`minutes` können über `add(hours, minutes)` durchrutschen, weil du dort nicht die Parameter prüfst, sondern den aktuellen Zustand (`totalMinutes()`).\n- In `add` wird die Precondition “Zeitspannen können nur verlängert werden” nicht korrekt geprüft: `totalMinutes() >= this.minutes` vergleicht Minuten mit Gesamtminuten und sagt nichts darüber aus, ob die Zeitspanne nach dem Addieren kleiner würde.\n- Negative Additionen werden nicht zuverlässig verhindert (z.B. `add(-1, 0)` kann ausgeführt werden), obwohl laut Aufgabe nur Verlängern erlaubt ist.\n- Die Invariante `0 ≤ getMinutes ≤ 59` ist nicht in allen Fällen garantiert: Bei `minutes < 0` verändert `checkMinutes()` die Minuten nicht sauber zurück in den erlaubten Bereich, und die Stundenkorrektur ist dabei falsch/unklar.\n\n### Suggestion\n- Prüfe im Konstruktor (und/oder in `add`) die Eingabeparameter direkt (`hours`, `minutes`) auf Negativwerte, statt den aktuellen Zustand abzufragen.\n- Für “nur verlängern” solltest du den alten Gesamtwert mit dem neuen Gesamtwert vergleichen (vorher/nachher), nicht `totalMinutes()` mit `this.minutes`.\n- Überlege dir eine klare Regel: Welche Eingaben sollen in `add` erlaubt sein? Wenn “nicht verkürzen” gilt, müssen Eingaben, die die Gesamtminuten reduzieren würden, abgewiesen werden.\n- Für `getMinutes` im Bereich 0..59: Normalisiere nach dem Addieren die Minuten so, dass Überträge (>=60) in Stunden umgerechnet werden; für negative Minuten solltest du entweder schon vorher verhindern, dass sie entstehen, oder die Normalisierung vollständig korrekt implementieren.\n\n### Code Style\n- `this.totalMinutes();` in `add` hat keinen Effekt (Rückgabewert wird ignoriert) und kann entfernt werden.\n- Fehlermeldungen wie `\"negativ\"` sind wenig aussagekräftig; formuliere sie konkreter (was ist negativ? welcher Parameter?).\n- `checkMinutes()` enthält Logik für negative Minuten, obwohl negative Zeitspannen laut Anforderungen gar nicht entstehen sollen; das macht den Code unnötig komplex und schwer nachvollziehbar.\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- In `findCommonSuperiorWith(other)` prüfst du im ersten `while`-Loop `if(commonSuperior.equals(superior))`, wobei `commonSuperior` konstant `this` ist. Dadurch findest du den gemeinsamen Vorgesetzten nur dann direkt in diesem Loop, wenn `other` (oder einer von dessen Bossen) exakt `this` ist; für den allgemeinen Fall ist diese Prüfung an dieser Stelle nicht passend zur Logik “erste gemeinsame Vorgesetzte finden” und kann zu verwirrendem/inkonsistentem Verhalten im Vergleich zum restlichen Algorithmus führen.\n\n### Suggestion\n- Überlege dir für `findCommonSuperiorWith`: Welche Menge willst du im ersten Schritt wirklich sammeln (Boss-Kette von wem?) und ab wann solltest du prüfen, ob ein Element in der anderen Kette vorkommt. Eine saubere Strategie ist: erst alle Vorgesetzten (inkl. Person selbst) von *einer* Seite sammeln und danach die Kette der *anderen* Seite von unten nach oben durchgehen und beim ersten Treffer stoppen.\n- Prüfe, ob du den “Sonderfall” `this == other` überhaupt separat brauchst, wenn du konsequent “jede Person ist ihr eigener Vorgesetzter” in deiner allgemeinen Schleifenlogik berücksichtigst.\n\n### Code Style\n- `import java.util.ArrayList;` und Verwendung von `ArrayList` sind hier ok, aber `new ArrayList<Employee>()` kann kürzer als `new ArrayList<>()` geschrieben werden.\n- Du mischst in `findCommonSuperiorWith` Referenzvergleich (`==`) und `equals()`. Da `Employee` kein `equals()` überschreibt, ist das zwar effektiv dasselbe wie `==`, wirkt aber inkonsistent. Entscheide dich konsequent für eine Variante.\n- Variablennamen wie `superior`/`commonSuperior` sind etwas irreführend, weil `commonSuperior` anfangs gar nicht “common” ist, sondern nur “current” auf der `this`-Kette. Ein präziserer Name würde die Lesbarkeit stark verbessern.\n\n\n# Exercise: smarthome\n\n### Correctness\n- `nightMode`: Du schaltest in den Bedrooms nicht **genau eine** Lampe pro Bedroom ein, sondern (durch deine Schleifen/Flags) eher alle Lampen eines einzigen Bedrooms und lässt die anderen Bedrooms unverändert.\n- `nightMode`: Die Bedingung „alle anderen Lampen werden ausgeschaltet“ wird nicht zuverlässig erfüllt, weil du das Ausschalten von Lampen von `room != rb`/`room != r` abhängig machst, während `room` in deiner äußeren Schleife nicht zu den gerade bearbeiteten Bedroom-/Hallway-Räumen passen muss.\n- `nightMode`: Du iterierst über `room.getLamps()` und führst darin wieder Schleifen über Hallway/Bedrooms aus – dadurch werden Lampen mehrfach (und abhängig von Iterationsreihenfolge) ein-/ausgeschaltet, was leicht zu falschen Endzuständen führt.\n- `saveEnergy`: Du gehst mit `lamps[0]` als Startwert davon aus, dass ein Raum immer mindestens eine Lampe hat; falls ein Raum ein leeres Lampen-Array hätte, wäre das nicht mehr korrekt (und würde abstürzen).\n\n### Suggestion\n- `nightMode`: Denk in zwei klaren Phasen: (1) zuerst überall alles ausschalten, (2) dann gezielt je **einen** Kandidaten pro gewünschtem Raum (Hallway + jeder Bedroom) einschalten und dimmen. Wenn du diese Schritte trennst, vermeidest du das „Hin-und-her“-Schalten durch verschachtelte Schleifen.\n- `nightMode`: Achte darauf, dass du deine „nur eine Lampe“-Logik **pro Raum** brauchst (z.B. ein Flag/Index pro Bedroom), nicht ein einziges `isOnB` für alle Bedrooms zusammen.\n- `nightMode`: Nutze wirklich das Ergebnis von `findBedrooms()` als Liste von Räumen und arbeite diese Räume direkt ab, statt innerhalb der Lampen-Schleife des gesamten Hauses wieder darüber zu iterieren.\n- `saveEnergy`: Überlege dir, wie du dich verhalten willst, wenn ein Raum keine Lampen hat, und bau eine kleine Abfrage ein, bevor du auf Element `0` zugreifst.\n\n### Code Style\n- `lampDirectory`/`getLampByName` werden in der Aufgabe nirgends gebraucht und bringen aktuell auch fachlich falsche Zuordnung (Key = Roomname, Value = nur eine Lampe pro Raum, letzte gewinnt). Das macht den Code unnötig komplex.\n- Viele unnötige Null-Checks wie `room.getLamps() != null`: In dieser Vorlage werden Lampen-Arrays typischerweise immer gesetzt; solche Checks erschweren die Lesbarkeit.\n- In `randomize` erstellst du in der inneren Schleife jedes Mal ein neues `Random`-Objekt; besser wäre, einen Generator zu verwenden.\n- `nightMode` ist stark verschachtelt (Schleife in Schleife in Schleife) und dadurch schwer nachvollziehbar; versuch die Logik in kleinere Hilfsmethoden aufzuteilen (z.B. „alle aus“, „schalte eine Lampe in Raum X auf Helligkeit Y“).\n",
"status" : "SUCCESS"
}
}