AutoFeedback API

Result 1416372b-9629-4e74-91da-5aaaa0a0bb44

{
  "llm" : {
    "feedback" : "# Exercise: address\n\n### Correctness\n- Im Konstruktor (und in allen Settern) setzt du die Felder **vor** der Validierung. Wenn ein ungültiges Argument übergeben wird, wird zwar eine `IllegalArgumentException` geworfen, aber das Objekt (bzw. der Setter-Aufruf) hat den Zustand vorher bereits auf ungültige Werte geändert – damit sind die Invarianten nicht durchgehend eingehalten.\n- In den Settern gilt dasselbe: Bei ungültigen Werten ist nach dem Methodenaufruf zwar eine Exception da, aber das Feld wurde schon überschrieben; damit kann ein `Address`-Objekt in einem ungültigen Zustand verbleiben.\n\n### Suggestion\n- Prüfe die Parameter **bevor** du sie in die Attribute übernimmst. Überlege dir: Was soll der Zustand des Objekts sein, wenn eine Exception fliegt? (Tipp: Der alte gültige Zustand sollte erhalten bleiben.)\n- Nutze für die Initialisierung im Konstruktor ggf. eine Strategie, die die gleiche Validierungslogik sicherstellt wie bei den Settern, ohne dass zwischenzeitlich ungültige Werte im Objekt landen.\n\n### Code Style\n- Die Parameternamen in den Settern (`bahnhofweg`, `basel`, `i`) sind irreführend; verwende sprechende, allgemeine Namen wie `street`, `city`, `number`, `zipCode`.\n- Die Fehlermeldungen bei Exceptions sind teils ungenau bzw. widersprüchlich (z.B. Zip-Code-Message spricht von “zero or negative”, geprüft wird aber “nicht vierstellig”). Formuliere Messages passend zur jeweiligen Regel.\n- Du duplizierst Validierungslogik an mehreren Stellen; das macht Änderungen fehleranfällig. Eine zentrale Validierung (oder Wiederverwendung) würde den Code wartbarer machen.\n\n\n# Exercise: timespan\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\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 nur genau die Lampen um, die du beim Finden “auffällig” findest. Gefordert ist aber: **in diesem Raum alle Lampen einschalten und auf 1.0 setzen** (also nicht nur die eine/n betroffene/n Lampe/n).\n- `turnNextRoomBright`: Nachdem `roomFound` gesetzt ist, kann die innere Lampen-Schleife im selben Raum trotzdem weiterlaufen und dabei weitere Lampen verändern (je nach Zustand). Das kann dazu führen, dass du **nicht konsistent alle Lampen im gewählten Raum** korrekt setzt.\n- `saveEnergy`: Du initialisierst `minPowerConsumption` mit `25.0`. Wenn ein Raum nur Lampen mit einem Verbrauch **>= 25.0** hätte, bleibt `cheapestLamp` `null` und dann würdest du danach auf `cheapestLamp.turnOn()` zugreifen (das würde schiefgehen). Die Aufgabe verlangt eine allgemein funktionierende Lösung.\n- `findHallway`: Du verwendest `contains(\"Hallway\")`, gefordert ist der Raum, der den Namen **\"Hallway\" hat** (also exakter Match, nicht “enthält”).\n\n### Suggestion\n- `turnNextRoomBright`: Überlege dir eine zwei-Phasen-Logik: zuerst einen Raum identifizieren (z.B. mit einem Flag “dieser Raum ist nicht komplett hell”), danach (nur für diesen einen Raum) in einer separaten Schleife **alle** Lampen auf `on` und `brightness=1.0` setzen.\n- `turnNextRoomBright`: Wenn du bei einem Raum entscheidest “das ist der nächste”, dann sollte die Entscheidung pro Raum fallen (nicht pro Lampe), damit du nicht mitten im Raumzustand hängen bleibst.\n- `saveEnergy`: Wähle den Startwert für “Minimum” so, dass er garantiert über jedem realen Lampenverbrauch liegt, oder starte mit der **ersten Lampe im Raum** als aktuelles Minimum und vergleiche dann die restlichen dagegen.\n- `findHallway`: Prüfe den Namen mit einem Vergleich, der wirklich nur dann true liefert, wenn der Name genau `\"Hallway\"` ist.\n\n### Code Style\n- In `turnNextRoomBright` und `findHallway` ist das Muster `boolean ...Found` + `if (!...Found)` verschachtelt relativ unübersichtlich. Eine klarere Blockstruktur bekommst du oft, wenn du die “Suche” und die “Aktion” stärker trennst (z.B. erst Ziel bestimmen, dann handeln).\n- In `nightMode` rufst du `findBedrooms()` direkt in der for-each Schleife auf. Lesbarkeit wird besser, wenn du das Ergebnis einmal in eine Variable speicherst (auch hilfreich fürs Debuggen).\n- Kleinigkeit: In `nightMode` verwendest du einmal `bedroom.getLamps().length` und hast gleichzeitig `Lamp[] bedroomLamps = ...`; konsistenter wäre, nur das Array zu verwenden, das du schon gespeichert hast.\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"
  }
}