{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Die Zip-Code-Validierung erfüllt die Anforderung „positiv und vierstellig“ nicht: Mit deiner Bedingung werden z.B. `1` oder `999` nicht zuverlässig ausgeschlossen, und Teile der Bedingung sind logisch redundant.\n- `getCity()` wirft bei leerer `city` eine `IllegalArgumentException`. Laut Aufgabe sollen Konstruktor und Setter bei ungültigen Argumenten werfen; ein Getter sollte hier nicht plötzlich validieren/werfen.\n- Die `format()`-Methode ist nicht `public`. Falls sie von außen (z.B. im Test oder in anderen Klassen) aufgerufen werden soll, ist sie so nicht zugreifbar.\n\n### Suggestion\n- Überlege dir für den Zip-Code einen klaren Wertebereich für „vierstellig“ und formuliere die Bedingung so, dass genau dieser Bereich akzeptiert wird (und alles andere nicht). Prüfe dabei auch, ob deine aktuellen Vergleiche überhaupt unterschiedliche Fälle abdecken.\n- Verlege die `city`-Validierung vollständig in Konstruktor und `setCity(...)`, und lass den Getter einfach den aktuellen Wert zurückgeben.\n- Prüfe, welche Sichtbarkeit (`public` vs. package-private) die Aufgabenstellung für `format()` nahelegt und wie die Methode typischerweise verwendet/getestet wird.\n\n### Code Style\n- Du hast die gleiche Validierungslogik mehrfach (street/number/zipCode/city) in Konstruktor und Settern. Das lässt sich oft durch private Hilfsmethoden reduzieren, damit du die Regeln nur an einer Stelle pflegen musst.\n- In `getCity()` steht eine Validierung, während `getStreet()` keine hat – das ist inkonsistent und macht das Verhalten der Getter schwer vorhersehbar.\n\n\n# Exercise: timespan\n\n### Correctness\n- In `add(...)` ist die Precondition zur Invariante `totalMinutes ≥ old(totalMinutes)` falsch umgesetzt: Du addierst nur, wenn `totalMinutes() >= hours*60 + minutes` gilt – das verhindert Verlängern und erlaubt eher „nicht verlängern“ (bzw. macht es abhängig von der Größe der Parameter statt vom Vergleich alt vs. neu).\n- Für die geforderte Precondition beim Verletzen von `totalMinutes ≥ old(totalMinutes)` wirfst du keine `IllegalArgumentException`, sondern lässt den Aufruf einfach (teilweise) ohne Effekt durchlaufen.\n- Die Invariante `0 ≤ getMinutes ≤ 59` ist in `add(...)` nicht zuverlässig umgesetzt: Deine Umrechnung prüft `if(minutes > 60)` mit dem **Parameter** `minutes` statt mit dem aktuellen Feld `this.minutes` nach dem Addieren. Damit kann `this.minutes` nach dem Addieren weiterhin ≥ 60 bleiben.\n- Deine `if(minutes > 60){ this.minutes = 0; this.hours++; }`-Logik ist zudem fachlich nicht korrekt für Fälle wie +130 Minuten (da müssten mehr als 1 Stunde übertragen werden und Restminuten bleiben).\n- Die Precondition „keine negativen Werte“ in `add(...)` wird zu spät geprüft (nachdem du bereits `checkMinutes()` aufgerufen hast) und damit nicht sauber „vorher“ durchgesetzt.\n\n### Suggestion\n- Überlege in `add(...)` genau, was „`totalMinutes` ≥ old(`totalMinutes`)“ bedeutet: Vergleiche den *neuen* Gesamtwert (alt + Zuwachs) mit dem *alten* Gesamtwert, statt den Zuwachs mit dem alten Wert zu vergleichen.\n- Wenn eine Precondition verletzt ist, sollte der Methodenaufruf klar scheitern: setze die Exception an den Anfang von `add(...)`, bevor du irgendetwas am Objektzustand änderst.\n- Normalisiere Minuten immer basierend auf dem tatsächlichen Objektzustand nach dem Addieren (`this.minutes`), nicht auf dem Parameter `minutes`. Teste gedanklich Fälle wie: Start 1h50, add 0h30 → 2h20; oder add 0h130 → +2h10.\n- Ersetze die „> 60 dann setze Minuten auf 0“ Idee durch eine allgemeine Umrechnung, die auch große Minutenwerte korrekt in Stunden + Restminuten umwandelt (und zwar ausgehend von `this.minutes`).\n\n### Code Style\n- Die Fehlermeldung `\"negativ\"` ist sehr knapp; eine aussagekräftigere Message (z.B. welche Werte ungültig waren) macht Debugging leichter.\n- In `add(...)` rufst du `checkMinutes()` mehrfach auf, teils bevor überhaupt etwas geändert wurde; das macht den Ablauf schwer nachvollziehbar. Consider: erst prüfen, dann ändern, dann einmal normalisieren.\n- Benenne lokale Variablen klarer (`divide` → z.B. `extraHours`), damit sofort ersichtlich ist, was berechnet wird.\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 alle Räume/Lampen hell (und schaltest sie ein), statt **nur den ersten Raum** zu finden, der noch nicht komplett „on + brightness 1.0“ ist, und **nur diesen** anzupassen; zudem passiert bei dir nicht „nichts“, wenn schon alles hell ist.\n- `saveEnergy`: Du schaltest/konfigurierst `minLamp` bereits **während** du noch suchst; dadurch kann am Ende nicht garantiert sein, dass wirklich die Lampe mit dem kleinsten Verbrauch eingeschaltet bleibt und alle anderen aus sind (die Aktionen gehören erst nach der Bestimmung der Minimum-Lampe).\n- `findBedrooms`: Du gibst praktisch immer nach dem ersten Durchlauf aus der Schleife zurück, sammelst also nicht alle Bedrooms im Haus.\n- `findBedrooms`: Dein `bedrooms`-Array wird innerhalb der Schleife jedes Mal wieder als leeres Array initialisiert, dadurch geht jede Sammlung verloren.\n- `findBedrooms`: Wenn ein Bedroom gefunden wird, kopierst du nur innerhalb einer Schleife über `bedrooms.length`—bei `0` passiert gar nichts, also wird das neue Bedroom nie eingefügt.\n- `findBedrooms`: Falls kein Bedroom gefunden wird, gibst du am Ende `rooms` zurück; gefordert ist aber ein Array, das nur Bedrooms enthält (darf größer sein und nulls haben, aber nicht einfach alle Räume).\n- `nightMode`: Nicht implementiert (TODO), obwohl es Teil der Aufgaben ist.\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir eine Abfrage „Sind **alle** Lampen in diesem Raum an **und** Helligkeit == 1.0?“—nur wenn das **nicht** gilt, ist das der Raum, den du bearbeiten solltest; danach solltest du nicht weiter über die restlichen Räume laufen.\n- `saveEnergy`: Trenne die Aufgabe in zwei Phasen: (1) pro Raum die Lampe mit minimalem Verbrauch bestimmen, (2) in einem zweiten Loop alle Lampen passend ein/aus schalten und Helligkeit setzen.\n- `findBedrooms`: Lege das Ergebnis-Array **einmal** an (maximal `rooms.length` groß ist ok) und verwalte zusätzlich einen Index/Zähler, an welche Position du den nächsten Bedroom speicherst.\n- `findBedrooms`: Platziere das `return` erst **nachdem** du alle Räume geprüft hast, nicht innerhalb der Schleife über `rooms`.\n- `nightMode`: Nutze als ersten Schritt deine `findHallway()` und `findBedrooms()` Ergebnisse, schalte zunächst alles aus, und schalte dann pro relevantem Raum genau **eine** Lampe ein (beliebig welche) und setze deren Helligkeit auf `0.3`.\n\n### Code Style\n- In `randomize()` erzeugst du in der inneren Schleife für jede Lampe ein neues `Random`-Objekt; nimm stattdessen einen Generator und verwende ihn mehrfach (macht den Code klarer und effizienter).\n- `turnNextRoomBright()` enthält eine verschachtelte Schleife `for (int i = 0; i < rooms.length; i++)` innerhalb einer `for (Room room : rooms)`-Schleife, obwohl `i` gar nicht benutzt wird—das wirkt wie ein Logik-/Kopierfehler und macht den Code unnötig komplex.\n- In `findBedrooms()` erzeugst du neue `Room`-Objekte (`new Room(...)`), obwohl du einfach die vorhandenen `Room`-Referenzen sammeln kannst; das macht den Code schwerer verständlich und ist unnötig.\n- Unnötige Null-Checks auf `room.getLamps() != null`: Laut Vorlage werden Lampen-Arrays beim Erstellen gesetzt; wenn du solche Checks trotzdem machst, dann konsequent und begründet (sonst eher weglassen für Lesbarkeit).\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"
}
}