{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor werden die Felder **vor** der Validierung gesetzt; bei ungültigen Argumenten wirfst du zwar eine `IllegalArgumentException`, aber das Objekt wurde dabei bereits (teilweise) in einen ungültigen Zustand gebracht.\n- In allen Settern passiert das Gleiche: Du weist den neuen Wert **zuerst** zu und prüfst **danach**. Wenn die Prüfung fehlschlägt, bleibt das Objekt in einem Zustand, der die Invarianten verletzt.\n\n### Suggestion\n- Prüfe die übergebenen Werte **bevor** du sie in die Felder schreibst (im Konstruktor wie auch in den Settern). So stellst du sicher, dass ein `Address`-Objekt nie sichtbar in einem ungültigen Zustand ist.\n- Du kannst die Validierungslogik pro Feld so strukturieren, dass bei einem Fehler **keine** Zuweisung passiert (z.B. erst prüfen, dann setzen).\n\n### Code Style\n- Die Setter-Parameternamen (`bahnhofweg`, `basel`, `i`) wirken wie Testwerte statt wie generische Parameternamen; nutze lieber sprechende, feldbezogene Namen (z.B. `street`, `city`, `number`, `zipCode`), das erhöht Lesbarkeit.\n- Die Fehlermeldung im Konstruktor ist sehr allgemein („Street cannot be empty“), obwohl auch andere Bedingungen fehlschlagen können; konsistentere/konkretere Messages erleichtern späteres Debugging.\n\n\n# Exercise: timespan\n\n### Correctness\n- Die Precondition im Konstruktor stellt nur sicher, dass `hours*60 + minutes >= 0`, aber nicht, dass die Zeitspanne “sinnvoll” ist im Sinne der Aufgabenstellung: Mit z.B. `hours = 1` und `minutes = -30` ist `totalMinutes` zwar nicht negativ, aber du erlaubst damit negative Minutenwerte als Eingabe, obwohl die Aufgabe “sinnvolle Preconditions für den Konstruktor” fordert.\n- In `add(...)` prüfst du ebenfalls nur, ob die Summe (`addedTotal`) negativ ist. Damit kann ein Client z.B. `add(1, -30)` aufrufen (positiver Gesamtzuwachs), obwohl dabei ein negativer Minutenparameter übergeben wird. Das unterläuft die Idee “nur verlängern” mit klaren Preconditions für die Methode.\n\n### Suggestion\n- Überlege dir, welche Bedingungen du **auf die einzelnen Parameter** im Konstruktor legen willst, damit aus Client-Sicht keine “negativen Anteile” in die Zeitspanne hineingelangen können, selbst wenn die Gesamtsumme zufällig noch ≥ 0 wäre.\n- Für `add(...)`: Formuliere die Precondition so, dass wirklich jede erlaubte Operation eine **Verlängerung** ist und nicht nur “in Summe nicht negativ”. Prüfe, ob deine aktuelle Bedingung Fälle zulässt, die zwar rechnerisch verlängern, aber negative Argumente enthalten.\n\n### Code Style\n- Die Fehlermeldung im Konstruktor ist missverständlich: “empty” passt bei `int`-Parametern nicht. Formuliere die Message so, dass sie genau beschreibt, welche Eingaben verboten sind (und warum).\n- Du hast ein Feld und eine Methode mit demselben Namen `totalMinutes`. Das ist zwar erlaubt, aber unnötig verwirrend beim Lesen. Eine klarere Benennung (entweder Feld oder Methode) würde die Verständlichkeit erhöhen.\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 setzt nur die Lampe(n) um, die du beim Prüfen findest; gefordert ist aber: **in diesem Raum alle Lampen** einschalten und auf **1.0** setzen, sobald der erste „nicht ganz helle“ Raum gefunden wurde.\n- `randomize`: Du setzt die Helligkeit mit `r.nextDouble(0.5, 1.0)`. Das erzeugt Werte in **[0.5, 1.0)**, also **1.0 wird nie erreicht**, obwohl „zwischen 0.5 und 1.0“ typischerweise inkl. 1.0 gemeint ist.\n- `saveEnergy`: Du initialisierst `minPowerConsumption` fix mit `25.0`. Wenn ein Raum nur Lampen mit höherem Verbrauch hätte, bleibt `cheapestLamp` `null` und die Methode würde beim Einschalten abstürzen; die Lösung soll aber allgemein für beliebige Lampen funktionieren.\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir eine Logik in zwei Phasen: (1) Raum finden, der das Kriterium verletzt, (2) wenn gefunden, in genau diesem Raum in einer separaten Schleife alle Lampen auf `on` und `brightness=1.0` setzen. Alternativ: erst merken „dieser Raum ist der gesuchte“ und erst nach der inneren Schleife reagieren.\n- `randomize`: Wenn du 1.0 als möglichen Wert brauchst, kannst du die Zufallszahl so konstruieren, dass der obere Rand nicht ausgeschlossen ist (z.B. über Skalierung/Addition und ggf. Clamping), statt die zweistellige `nextDouble(origin,bound)`-Variante zu verwenden.\n- `saveEnergy`: Setze den Startwert für das Minimum so, dass er garantiert über jedem realen Verbrauch liegt, oder nimm als Startminimum die erste Lampe im Raum und vergleiche dann ab der zweiten. Damit vermeidest du, dass `cheapestLamp` am Ende `null` bleibt.\n\n### Code Style\n- `lampIndex` und `getLampByName` werden in den geforderten SmartHome-Funktionen nicht verwendet und erhöhen unnötig die Komplexität; wenn das nicht explizit verlangt ist, eher weglassen.\n- Viele `if (!...Found)`-Konstrukte (z.B. in `findHallway`, `turnNextRoomBright`) machen die Blockstruktur schwerer lesbar; das lässt sich oft klarer ausdrücken, wenn du den Fundstatus pro Raum/Schleife strukturierst oder Hilfsmethoden nutzt.\n- `Random r = new Random();` in mehreren Methoden: entweder als Feld wiederverwenden oder konsistent pro Aufruf erstellen; aktuell ist es gemischt und etwas unruhig.\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"
}
}