{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n\n### Suggestion\n\n### Code Style\n- Im Konstruktor setzt du die Felder in einer anderen Reihenfolge als die Parameterliste (number/city/street/zipCode). Das ist zwar funktional ok, aber verwirrend beim Lesen und Debuggen; konsistenter wäre dieselbe Reihenfolge wie in der Signatur.\n- In `setZipCode` ist `String.valueOf(zipCode).length() != 4` etwas indirekt; die Intention „vierstellig“ ist damit zwar umsetzbar, aber weniger klar lesbar als eine rein numerische Prüfung.\n- Die geworfenen `IllegalArgumentException`s haben keine Fehlermeldung. Eine kurze Message würde das Finden der Ursache bei Tests deutlich erleichtern.\n\n\n# Exercise: timespan\n\n### Correctness\n- \n\n### Suggestion\n- \n\n### Code Style\n- In deiner Klasse ist `toString()` zwar hilfreich, aber im bereitgestellten Exercise-Code war sie nicht gefordert; prüfe, ob Zusatzmethoden in deiner Abgabe erlaubt sind.\n- Die Fehlermeldung `\"no negative values permitted\"` ist okay, aber überlege, ob du sie spezifischer machen willst (z.B. welche Parameter ungültig waren), damit Client-Code einfacher debuggen kann.\n\n\n# Exercise: asteroids\n\n### Correctness\n- In `AsteroidsGame` fehlt ein echter Java-Programmeinstiegspunkt (`public static void main(String[] args)`); die Methode heisst bei dir nur `void main()`, wodurch das Programm je nach Setup nicht startbar ist.\n- Die geforderte Klasseninvariante beim `Falcon` ist nicht umgesetzt (du begrenzt zwar per `clamp`, aber es gibt keine Invariante/Assertion, die diese Bedingung als Invariante festhält).\n- Die Kollisionsberechnung verwendet bei dir `size * 64` als Asteroiden-Radius, obwohl in der Aufgabe gefordert ist, dass die Kollision über die Summe der “Grössen (Radien)” von Falcon und Asteroid läuft; durch die zusätzliche Umrechnung in Pixel kann die Kollision deutlich anders ausfallen als gefordert.\n- Wenn `gameOver` eintritt, zeichnest du den Game-Over-Schriftzug, rufst aber danach trotzdem `gui.refreshAndClear(20)` auf; dadurch wird der Frame unmittelbar wieder gelöscht und der Schriftzug ist ggf. gar nicht sichtbar (oder nur extrem kurz).\n\n### Suggestion\n- Schau dir an, welche Methodensignatur Java als Einstieg erwartet und wie die bestehende `AsteroidsGame`-Struktur das normalerweise löst.\n- Überlege, wie du eine Invariante in Java sichtbar “festnageln” kannst (z.B. durch `assert` oder eine zentrale Prüfmethode, die nach Konstruktor/`move` aufgerufen wird), statt dich nur auf `clamp` zu verlassen.\n- Entscheide dich für eine konsistente Definition von “Radius/Grösse” für Asteroid und Falcon: Entweder arbeitest du überall in denselben Einheiten (z.B. “Radius” als eigene Variable) oder leitest ihn sauber aus `size` ab – aber vermeide magische Faktoren wie `64`, wenn sie nicht aus den Anforderungen kommen.\n- Wenn das Spiel vorbei ist: Überlege, ob du wirklich noch “clear” willst. Eine einfache Möglichkeit ist, nach dem Zeichnen von “game over” nicht mehr zu löschen oder ausserhalb der Loop in einer separaten Anzeige-Schleife zu warten.\n\n### Code Style\n- `checkCollisions()` kann frühzeitig abbrechen, sobald eine Kollision gefunden wurde (statt weiter zu iterieren und ein Flag zu setzen).\n- In `Asteroid` und `Falcon` wären klar benannte Konstanten für “Bildskalierung vs. Kollisionsradius” hilfreich, damit nicht unklar bleibt, warum `RADIUS = 32` und warum (falls nötig) eine Umrechnung zwischen `size` und Radius passiert.\n\n\n# Exercise: bosses\n\n### Correctness\n*(leer)*\n\n### Suggestion\n*(leer)*\n\n### Code Style\n*(leer)*\n\n\n# Exercise: smarthome\n\n### Correctness\n- `nightMode` verwendet `if (hallway.getLamps().length > 0)` ohne vorher zu prüfen, ob `findHallway()` tatsächlich etwas gefunden hat; falls `findHallway()` `null` zurückgibt, kommt es hier zu einer `NullPointerException` (die Methode selbst garantiert den Rückgabewert gemäss Aufgabenannahme nicht).\n- `findHallway` läuft zwar über alle Räume, aber wenn es (entgegen der Annahme) mehrere passende gäbe, würdest du den *letzten* statt den “einen” zurückgeben; das ist nicht das, was “findet den Raum … und gibt ihn zurück” typischerweise meint.\n\n### Suggestion\n- Überlege dir bei `findHallway`, wie du sicherstellen kannst, dass nach dem Finden nicht nochmals überschrieben wird (ohne `break`/early return). Ein boolesches Flag, wie du es in `turnNextRoomBright` machst, passt hier gut.\n- In `nightMode`: Wenn du dich darauf verlässt, dass es genau eine Hallway gibt, kannst du `findHallway` so bauen, dass er garantiert eine gültige Referenz liefert. Alternativ könntest du vor dem Zugriff defensiv prüfen, ob das Ergebnis `null` ist (auch wenn es laut Aufgabe “eigentlich nie” passieren sollte).\n\n### Code Style\n- Duplikation von Zugriffen wie `hallway.getLamps()[0]` bzw. `room.getLamps()[0]`: speichere die Lampen-Referenz kurz in eine Variable, dann ist es lesbarer und weniger fehleranfällig.\n- `isFullyBright`: Du setzt `bright` auf `false`, prüfst aber danach weiter alle Lampen; das ist zwar erlaubt, aber unnötige Arbeit. Wenn du schon “ohne break/early return” bleiben willst, könntest du die Schleifenbedingung/Blockstruktur so gestalten, dass nach dem ersten “nicht hell” keine weiteren Checks mehr passieren.\n- In `findBedrooms` ist `count` ok, aber der Name suggeriert eine “exakte” Liste. Da du absichtlich `null`-Einträge tolerierst, wäre ein kurzer Kommentar hilfreich, damit klar ist, dass das so gewollt ist.\n",
"status" : "SUCCESS"
}
}