{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor werden die Felder zuerst gesetzt und erst danach validiert; bei ungültigen Argumenten wird damit kurzzeitig ein Objekt mit verletzten Invarianten aufgebaut (die Anforderungen verlangen, dass Konstruktor/Setter bei ungültigen Argumenten eine `IllegalArgumentException` werfen und die Invarianten sicherstellen).\n- In allen Settern wird zuerst der neue Wert zugewiesen und erst danach geprüft; bei ungültigen Argumenten bleibt das Objekt anschließend in einem ungültigen Zustand, obwohl eine Exception geworfen wurde.\n\n### Suggestion\n- Prüfe die Argumente im Konstruktor, bevor du sie den Feldern zuweist (oder delegiere im Konstruktor an die Setter, die dann korrekt validieren), sodass ein fehlerhafter Aufruf gar keinen “halb-initialisierten” Zustand erzeugen kann.\n- In den Settern: validiere zuerst den übergebenen Parameter und weise erst dann dem Attribut zu; so bleibt das Objekt auch nach einer geworfenen Exception unverändert gültig.\n\n### Code Style\n- Die Parameternamen in den Settern (`bahnhofweg`, `basel`, `i`) sind unpassend/irreführend; verwende sprechende, zur Bedeutung passende Namen wie `street`, `city`, `number`, `zipCode`.\n- Die Fehlermeldungen sind teils ungenau bzw. passen nicht zu allen Prüfungen (z.B. Zip-Code-Text spricht von “zero or negative”, geprüft wird aber “nicht vierstellig”); formuliere Messages passend zur jeweiligen Invariante.\n\n\n# Exercise: timespan\n\n### Correctness\n- In `add(...)` prüfst du nur, ob die Summe `(hours*60 + minutes)` negativ ist. Damit sind Kombinationen möglich, die die Zeitspanne effektiv verkürzen, obwohl weder `hours` noch `minutes` einzeln negativ sind (z.B. positive Stunden und stark negative Minuten), was die Invariante „nur verlängern“ verletzt.\n- Im Konstruktor prüfst du nur `totalMinutes < 0`. Damit sind Eingaben möglich, die zwar insgesamt nicht negativ sind, aber trotzdem negative Einzelwerte enthalten (z.B. `hours = -1, minutes = 120`). Die Aufgabe verlangt „sinnvolle Preconditions“ für den Konstruktor; reine Gesamtprüfung lässt solche Fälle durch.\n\n### Suggestion\n- Überlege für `add(...)`, welche Bedingung wirklich sicherstellt, dass die Zeitspanne nicht kleiner wird als vorher. Ein Check nur auf die Summe der Parameter reicht nicht, wenn du die Parameter einzeln als Stunden/Minuten interpretierst.\n- Formuliere die Preconditions für Konstruktor und `add(...)` so, dass Eingaben mit negativen Komponenten gar nicht erst akzeptiert werden, statt nur den Gesamtwert zu betrachten. Prüfe dazu, welche Wertebereiche für `hours` und `minutes` als Eingabe sinnvoll sind, wenn du sie als „Dauer“ interpretierst.\n\n### Code Style\n- Die Fehlermeldung im Konstruktor („cannot be empty“) passt nicht zur Prüfung (du prüfst nur negativ/gesamt) und ist semantisch irreführend.\n- Du hast ein Feld und eine Methode mit demselben Namen `totalMinutes`. Das ist zwar legal, aber unnötig verwirrend; unterschiedliche Namen verbessern Lesbarkeit.\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 schaltest nicht **alle** Lampen im gefundenen Raum auf `on` und `brightness = 1.0`, sondern nur die Lampen, die du gerade als “nicht ok” erkennst; Lampen, die z.B. `on=false` und `brightness=1.0` sind, werden nicht zwingend alle eingeschaltet, und Lampen die zwar ok sind, werden von dir nicht nochmals gesetzt (gefordert ist: *in diesem Raum werden alle Lampen eingeschaltet und auf volle Helligkeit gesetzt*).\n- `turnNextRoomBright`: Sobald du einen “passenden” Raum findest, setzt du `roomFound = true`, aber du brichst die innere Schleife nicht ab; dadurch können in diesem Raum Lampen, die nach der ersten gefundenen “nicht ok”-Lampe kommen, unberührt bleiben, obwohl der Raum ja komplett “bright” gemacht werden soll.\n- `saveEnergy`: Du initialisierst `minPowerConsumption` mit `25.0`. Wenn ein Raum nur Lampen mit höherem Verbrauch hätte, bleibt `cheapestLamp` `null` und du würdest danach `cheapestLamp.turnOn()` aufrufen (NullPointerException). Die Aufgabe verlangt eine allgemeine Lösung für beliebige Räume/Lampen.\n- `findHallway`: Du verwendest `contains(\"Hallway\")`, gefordert ist aber ein Raum, der den Namen **\"Hallway\" hat** (also Gleichheit, nicht “enthält”).\n- `nightMode`: Es wird verlangt, dass `nightMode` die Methoden `findHallway` und `findBedrooms` verwendet. Du verwendest sie zwar, aber du implementierst dabei keine der in der Vorlage erwähnten “vorgegebenen Hilfsmethoden” (falls diese in eurer eigentlichen Vorlage existieren). Falls diese Teil der Aufgabenstruktur sind, fehlt das.\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir eine Struktur in zwei Phasen: (1) Prüfen, ob der Raum der “erste nicht perfekte” ist (ohne etwas zu verändern), (2) wenn ja, dann in einer separaten Schleife wirklich **jede** Lampe in genau diesem Raum einschalten und auf 1.0 setzen.\n- `turnNextRoomBright`: Wenn du einen Raum gefunden hast, solltest du verhindern, dass du im selben Raum nur “teilweise” etwas machst. Denke darüber nach, wie du nach dem Finden des Raums die restlichen Lampen im Raum trotzdem sicher behandelst.\n- `saveEnergy`: Wähle den Startwert für “Minimum” so, dass er für beliebige Lampen funktioniert, oder initialisiere das Minimum mit der ersten Lampe des Raums (und starte die Suche dann ab der zweiten).\n- `findHallway`: Verwende einen Vergleich, der wirklich nur dann zutrifft, wenn der Name exakt \"Hallway\" ist.\n- `nightMode`: Falls eure Vorlage wirklich schon Hilfsmethoden für `nightMode` enthält: Implementiere diese zuerst und baue `nightMode` dann darauf auf (das wird oft auch in Tests erwartet).\n\n### Code Style\n- Du hast zusätzliche Infrastruktur (`lampIndex`, `getLampByName`) eingebaut, die in der Aufgabe nicht verlangt wird und im restlichen Code nicht verwendet wird; das macht die Lösung unnötig komplex.\n- In `Room` hast du das Feld von `Lamp[]` auf `ArrayList<Lamp>` geändert. Das weicht von der Vorlage ab und kann in einer Übungsumgebung/Autotests schnell zu Inkompatibilitäten führen, auch wenn du nach außen wieder ein Array lieferst.\n- Viele bool-Flags wie `roomFound`/`hallwayFound` dienen bei dir als Ersatz für einen Schleifenabbruch. Die Aufgabe empfiehlt explizit saubere Blockstruktur ohne `break`/`continue`/early return — mit Flags geht das zwar, aber es wird schnell unübersichtlich. Prüfe, ob du die Bedingungen so strukturieren kannst, dass weniger “Merker-Variablen” nötig sind.\n- Bei `brightness`-Vergleich nutzt du `!= 1.0`. Floating-Point-Vergleiche sind stilistisch heikel; selbst wenn hier meist ok, wäre ein toleranzbasierter Vergleich robuster.\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"
}
}