{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n \n\n### Suggestion\n \n\n### Code Style\n- Die Fehlermeldungen in den `IllegalArgumentException`s sind teils unterschiedlich formatiert (z.B. Groß-/Kleinschreibung bei „number“/„Street“); einheitliche Messages machen Debugging/Tests oft angenehmer.\n- In `format()` greifst du direkt auf die Felder zu; konsistenter wäre es, überall denselben Zugriffspfad zu nutzen (entweder konsequent Felder oder konsequent Getter), um spätere Änderungen leichter zu machen.\n- Die Konstanten `LOWEST_ZIP_CODE`/`HIGHEST_ZIP_CODE` sind sinnvoll; benenne sie ggf. noch so, dass klar ist, dass sie für „4-stellig“ stehen (Lesbarkeit).\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Fehlermeldung in der `IllegalArgumentException` ist inhaltlich falsch: Du erlaubst `0`, aber der Text sagt „must be over 1“ (und ist damit irreführend im Sinne der geforderten Preconditions „nicht negativ“).\n- Deine Preconditions in `add` verhindern zwar negative Parameter, aber die Invariante „Zeitspannen können nur verlängert werden, nicht verkürzt“ bezieht sich auf `totalMinutes` insgesamt; mit der aktuellen Logik wird nicht explizit abgesichert, dass `totalMinutes()` nach `add` nie kleiner als vorher sein kann (die Aufgabe verlangt eine entsprechende Precondition dafür).\n\n### Suggestion\n- Passe den Exception-Text so an, dass er genau das beschreibt, was du prüfst (nicht negativ), damit Client-Code bei Fehlern korrekte Hinweise bekommt.\n- Überlege dir, wie du vor dem Addieren den alten Gesamtwert (in Minuten) mit dem neuen Gesamtwert vergleichen könntest, um die „nie verkürzen“-Bedingung wirklich als Precondition auszudrücken (insbesondere falls du später die erlaubten Eingaben/Logik änderst).\n\n### Code Style\n- In `add` überschreibst du die Parameter `hours`/`minutes` mit neuen Werten (die eigentlich „newHours/newMinutes“ sind). Das ist verwirrend; benutze dafür lieber eigene lokale Variablen mit sprechenden Namen.\n- Die Fehlermeldung („over 1“) ist nicht nur fachlich falsch, sondern auch sprachlich unklar; Formuliere sie präzise und konsistent (z.B. „must be non-negative“).\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- `isSuperiorOf` wirft eine `NullPointerException`, wenn `other == null` übergeben wird (du greifst sofort auf `other.boss` zu).\n- `findCommonSuperiorWith` wirft ebenfalls eine `NullPointerException`, wenn `other == null` ist.\n- `findCommonSuperiorWith` verändert den Parameter `other` durch Hochwandern in der Boss-Kette; falls in Tests erwartet wird, dass das übergebene Objekt/Referenz „logisch unverändert“ bleibt (z.B. weil man später mit derselben Referenz weiterrechnet), kann das zu unerwartetem Verhalten führen.\n\n### Suggestion\n- Überlege dir, welche Eingaben laut Aufgabe vorkommen können (insbesondere `null`) und wie du solche Fälle direkt am Anfang der Methode abfangen kannst, bevor du auf Felder zugreifst.\n- Nutze für das Hochwandern lieber eine lokale Hilfsvariable (z.B. `current`) statt den Parameter selbst „umzuhängen“; so bleibt der ursprüngliche Wert von `other` erhalten.\n\n### Code Style\n- In `isSuperiorOf` und `findCommonSuperiorWith` greifst du direkt auf `other.boss` zu; konsistenter (und kapselungsfreundlicher) wäre es, über `getBoss()` zu gehen, statt Felder anderer Objekte direkt zu verwenden.\n- Der Kommentar zu `isSuperiorOf` ist sehr ausführlich, aber ein Teil davon beschreibt Sonderfälle, die sich aus der Logik schon ergeben; kürzer und präziser wäre leichter wartbar.\n\n\n# Exercise: smarthome\n\n### Correctness\n- In `randomize()` verwendest du `random.nextDouble(MIN_VALUE_RANDOMIZE, MAX_VALUE_RANDOMIZE)`. Diese Überladung existiert erst in neueren Java-Versionen; je nach Kurs-/Prüfungsumgebung kann das nicht kompilieren. Die Aufgabe verlangt zwar Zufallswerte, aber nicht zwingend diese API.\n- In `turnNextRoomBright()` prüfst du `lamp.getBrightness() != 1.0`. Durch double-Vergleiche kann ein Raum fälschlicherweise als „nicht voll hell“ gelten, obwohl er logisch auf 1.0 gesetzt wurde (Floating-Point-Problematik). Damit kann die Methode einen Raum „nochmal“ aufhellen, obwohl eigentlich schon alle Räume voll hell sind.\n\n### Suggestion\n- Schau nach, welche Java-Version bei euch vorausgesetzt ist. Falls `nextDouble(min,max)` nicht verfügbar ist: Überlege, wie du mit `nextDouble()` (0..1) und einer passenden Skalierung/Addition trotzdem in den Bereich `[0.5, 1.0)` kommst.\n- Für die „voll hell“-Prüfung: Überlege dir eine robustere Bedingung als exaktes `!= 1.0` bei doubles, z.B. über eine Toleranz oder indem du prüfst, ob die Helligkeit „nahe genug“ an 1.0 ist.\n\n### Code Style\n- Du hast mehrere „Magic Numbers“ sinnvoll als Konstanten gelöst, das ist gut; konsequent wäre, `MAX_VALUE_RANDOMIZE` auch als `1.0` (double) zu schreiben statt `1`.\n- `findHallway()` arbeitet mit einem `while` ohne sichtbare Schranke; da die Aufgabe zwar garantiert, dass es genau eine Hallway gibt, wäre es lesbarer, wenn die Schleifenbedingung auch zeigt, dass du über das Array iterierst (auch wenn es logisch nicht nötig ist).\n- In `nightMode()` und `findBedrooms()` nutzt du einmal for-each und einmal while mit Index; ein einheitlicher Iterationsstil würde die Lesbarkeit erhöhen.\n",
"status" : "SUCCESS"
}
}