AutoFeedback API

Result ed8b8ad2-0ba2-443d-8295-845af4fbe242

{
  "llm" : {
    "feedback" : "# Exercise: address\n\n### Correctness\n- `getCity()` wirft eine `IllegalArgumentException`, wenn `city` leer ist; gefordert ist das Werfen nur im Konstruktor oder in den Settern bei ungültigen Argumenten (Getter sollen normalerweise nichts validieren/werfen).\n- In `getCity()` prüfst du nur `city.isEmpty()`, aber nicht `city == null`; falls `city` jemals `null` wäre, gäbe es hier eine `NullPointerException` statt der geforderten `IllegalArgumentException`.\n\n### Suggestion\n- Verschiebe die Validierung der `city`-Invariante vollständig in Konstruktor und `setCity(...)`, und lass den Getter einfach den gespeicherten Wert zurückgeben.\n- Überlege, wie du sicherstellen kannst, dass `city` nie `null` wird, sodass ein Getter keine zusätzlichen Checks braucht (und damit auch keine unerwarteten Exceptions wirft).\n\n### Code Style\n- Du wiederholst die gleichen Validierungs-Blöcke in Konstruktor und Settern; um Duplikation zu vermeiden, könntest du die Prüfungen zentralisieren (z.B. über private Hilfsmethoden oder indem der Konstruktor die Setter nutzt).\n\n\n# Exercise: timespan\n\n### Correctness\n- In `add(...)` setzt du die Precondition für „Zeitspannen können nur verlängert werden“ nicht korrekt um: `if(totalMinutes() >= this.minutes)` vergleicht zwei unterschiedliche Dinge (Gesamtminuten vs. nur Minutenanteil) und hat nichts mit „old(totalMinutes)“ im Sinne der Aufgabe zu tun.\n- Durch die aktuelle Bedingung in `add(...)` kann eine gültige Verlängerung fälschlicherweise gar nicht durchgeführt werden (weil der `if`-Block dann übersprungen wird), obwohl sie die Invariante erfüllen würde.\n- `add(...)` erlaubt effektiv trotzdem eine Verkürzung: z.B. `add(0, -1)` wird zwar abgefangen, aber `add(-1, 0)` wird auch abgefangen; allerdings fehlt eine Precondition, die auch Kombinationen verhindert, die die Gesamtzeit verkleinern würden, falls du später andere Logik änderst. Entscheidend ist: Die Regel muss auf `totalMinutes`-Basis formuliert und geprüft werden, nicht nur „keine negativen Parameter“.\n- Die Invariante „0 ≤ getMinutes ≤ 59“ gilt bei dir nur dann, wenn `checkMinutes()` ausgeführt wird. Das passiert zwar im Konstruktor und in `add`, aber dein Code verhindert nicht, dass `minutes` intern zwischenzeitlich (innerhalb von `add`) kurz ungültig ist; in dieser Aufgabe zählt vor allem das beobachtbare Verhalten, aber du solltest sicherstellen, dass nach `add` garantiert normalisiert ist (inkl. Fällen wie sehr großen Minutenwerten – das deckt deine `checkMinutes()` zwar ab, aber nur wenn `add` wirklich ausgeführt wird).\n\n### Suggestion\n- Überlege dir für die „nicht verkürzen“-Regel: Welche Größe beschreibt die Zeitspanne eindeutig von außen? Prüfe vor dem Ändern den alten Wert und vergleiche ihn mit dem neuen, der durch die Parameter entstehen würde.\n- Die Bedingung in `add(...)` sollte sich auf die Veränderung der gesamten Zeitspanne beziehen (also auf Minuten insgesamt), nicht auf den aktuellen Minutenanteil (`this.minutes`).\n- Achte darauf, dass eine gültige Verlängerung niemals „still“ ignoriert wird. Wenn eine Precondition verletzt ist, sollte eine Exception fliegen; wenn sie erfüllt ist, sollte die Änderung auch passieren.\n\n### Code Style\n- Fehlermeldung `\"negativ\"` ist wenig aussagekräftig; verwende eine klare Message, die erklärt, was nicht erlaubt ist (z.B. negative Werte / Verkürzung).\n- Benennung `checkMinutes()` passt nicht ganz: die Methode normalisiert/konvertiert Minuten in Stunden. Ein Name, der das ausdrückt, wäre verständlicher.\n- In `checkMinutes()` verwendest du einmal `this.minutes` und einmal `minutes` ohne `this` (`this.minutes = minutes - ...`). Das funktioniert zwar, ist aber inkonsistent und kann beim Lesen verwirren.\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` macht nicht das Geforderte: Du hellst nicht nur den *ersten* passenden Raum auf, sondern bearbeitest effektiv alle Räume und setzt dort Lampen auf 1.0.\n- `turnNextRoomBright`: Die Logik „Raum finden, in dem *nicht alle* Lampen an und auf 1.0 sind“ wird nicht korrekt geprüft; zudem verwendest du eine innere Schleife über `rooms.length`, die nichts mit der Auswahl des nächsten Raums zu tun hat und die Wirkung vervielfacht.\n- `saveEnergy`: Die kleinste Lampe pro Raum wird nicht zuverlässig korrekt behandelt, weil du `minLamp.turnOn()` / `setBrightness(0.8)` innerhalb der Suchschleife ausführst (also während `minLamp` noch wechseln kann).\n- `saveEnergy`: „Alle anderen Lampen werden ausgeschaltet“ wird nicht korrekt garantiert, weil du nur Lampen ausschaltest, wenn sie gerade `isOn()` sind (die Anforderung ist unabhängig vom aktuellen Zustand).\n- `findBedrooms` gibt nicht alle Bedrooms zurück: Du initialisierst `bedrooms` in jeder Iteration neu, brichst durch `return bedrooms` bereits in der ersten Schleifenrunde ab und verlierst damit spätere Treffer.\n- `findBedrooms`: Dein Array-Aufbau funktioniert nicht, weil du nur innerhalb einer Schleife über `bedrooms.length` kopierst; bei `bedrooms.length == 0` wird der neue Eintrag nie gesetzt.\n- `findBedrooms`: Falls kein Bedroom im ersten betrachteten Raum gefunden wird, gibst du am Ende `rooms` zurück; gefordert ist aber ein Array mit (nur) den Bedroom-Räumen (ggf. mit `null`-Einträgen), nicht einfach alle Räume.\n- `nightMode` ist nicht implementiert.\n\n### Suggestion\n- Bei `turnNextRoomBright`: Trenne die Aufgabe in zwei Schritte: (1) Prüfen pro Raum, ob **alle** Lampen `on` sind **und** `brightness == 1.0`; (2) Beim **ersten** Raum, der diese Bedingung nicht erfüllt, dann alle Lampen dort auf an + 1.0 setzen und danach nichts mehr ändern.\n- Bei `turnNextRoomBright`: Überlege dir eine boolesche Variable pro Raum wie „roomAlreadyBright“ und aktualisiere sie beim Durchlaufen der Lampen; so kannst du nach der Lampen-Schleife entscheiden, ob du diesen Raum „aufhellen“ musst.\n- Bei `saveEnergy`: Suche zuerst wirklich nur die Lampe mit minimalem Verbrauch (eine reine „min finden“-Phase). Erst danach in einem zweiten Durchlauf im selben Raum: genau diese Lampe einschalten + Helligkeit setzen und alle anderen ausschalten.\n- Bei `saveEnergy`: Schalte die anderen Lampen unabhängig von `isOn()` aus, damit der Endzustand sicher stimmt.\n- Bei `findBedrooms`: Lege das Ergebnisarray **einmal** an (maximal `rooms.length` groß) und fülle es mit einem separaten Index/Zähler, den du erhöhst, wenn du einen Bedroom findest.\n- Bei `findBedrooms`: Erstelle keine neuen `Room`-Objekte; du sollst die existierenden Räume aus `rooms` zurückgeben.\n- Bei `nightMode`: Nutze zuerst `findHallway()` und `findBedrooms()`, schalte initial alles aus, und schalte dann in den relevanten Räumen jeweils genau *eine* Lampe an und setze deren Helligkeit auf 0.3 (welche Lampe ist egal, z.B. die erste im Lampen-Array).\n\n### Code Style\n- In `randomize` erzeugst du für jede Lampe ein neues `Random`-Objekt; ein einzelner `Random` reicht (und macht das Verhalten nachvollziehbarer).\n- `findBedrooms` ist unnötig kompliziert (neue `Room`-Objekte, mehrfaches Array-Kopieren) und dadurch schwer lesbar; eine einfache Sammellogik mit Ergebnisindex wäre deutlich klarer.\n- Uneinheitliche Einrückung/Klammerung (z.B. in `saveEnergy`) erschwert das Lesen; formatiere konsequent.\n- Der `null`-Check auf `room.getLamps()` ist wahrscheinlich unnötig, weil `Room` laut Vorlage immer ein Lampen-Array bekommt; wenn du ihn behältst, dann konsequent und ohne doppelte Logikblöcke.\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"
  }
}