{
"llm" : {
"feedback" : "# Exercise: address\n\n### Correctness\n- Bei `zipCode` stellst du nur die Vierstelligkeit sicher (`1000–9999`), aber die Anforderung sagt zusätzlich „positiv“: aktuell würde z.B. `0000` zwar nicht durchgehen, aber es ist nicht explizit als „positiv“ geprüft (je nach Interpretation könnte „vierstellig“ auch `0123` meinen, was mit `int` sowieso nicht darstellbar ist).\n\n### Suggestion\n- Überlege dir, was „positiv und vierstellig“ bei einem `int` genau bedeutet, und formuliere die Bedingung so, dass beide Teile der Invariante eindeutig erfüllt sind (und dokumentiere ggf. kurz, wie du „vierstellig“ interpretierst).\n\n### Code Style\n- Du könntest in `format()` direkt auf die Felder zugreifen statt über Getter (ist in der eigenen Klasse üblich), oder konsequent überall Getter nutzen – wichtig ist hier eher Einheitlichkeit.\n- Die Exception-Texte sind gemischt deutsch/englisch (z.B. `zipCode`), das kann man vereinheitlichen, damit es konsistent wirkt.\n\n\n# Exercise: timespan\n\n### Correctness\n- Im Konstruktor ist die Precondition für „Zeitspannen sind nie negativ (totalMinutes ≥ 0)“ nicht sauber durchgesetzt: Durch die `||`-Verknüpfung akzeptierst du Kombinationen, die einzelne negative Werte enthalten (z.B. `hours < 0` und `minutes > 0`), obwohl die Aufgabenstellung „sinnvolle Preconditions“ verlangt und negative Eingaben über Exceptions abfangen will.\n- In `add(...)` erzwingst du nicht die geforderte Invariante `totalMinutes ≥ old(totalMinutes)` für alle Fälle: Du erlaubst z.B. negative `hours` solange die Summe `hours*60+minutes` nicht negativ ist (oder umgekehrt), wodurch die Zeitspanne verkürzt werden kann, obwohl das laut Aufgabe nie passieren darf.\n- Deine Normalisierung in `add(...)` mit `while (this.minutes < 0)` macht es möglich, dass `getMinutes()` zwar wieder im Bereich 0..59 landet, aber die Gesamtdauer dabei reduziert wird (du „leihst“ Stunden aus) – das widerspricht der „nur verlängern“-Vorgabe.\n\n### Suggestion\n- Überlege dir für den Konstruktor: Welche Eingaben sollten aus Client-Sicht überhaupt erlaubt sein, wenn Zeitspannen „nie negativ“ sind? Formuliere die Precondition so, dass sie nicht durch einzelne negative Parameter „ausgetrickst“ werden kann.\n- Für `add(...)`: Prüfe die Bedingung nicht nur gegen „nicht negativ“, sondern gegen „nicht verkürzen“. Eine hilfreiche Denkrichtung ist: Vergleiche die Dauer *vorher* mit der Dauer *nachher* (oder prüfe, dass der Zuwachs nicht negativ ist).\n- Wenn du Minuten normalisierst: Achte darauf, dass die Normalisierung keine semantische „Korrektur“ nach unten erlaubt (wie bei `minutes < 0`). Wenn negative Minuten überhaupt nicht erlaubt sein sollen, sollte das eher über Preconditions verhindert werden als über nachträgliches „Reparieren“.\n\n### Code Style\n- Die Bedingungen im Konstruktor sind schwer lesbar (`(minutes >= 0 && hours >= 0) || hours * 60 + minutes >= 0`); klarere, direkt zur Aufgabe passende Bedingungen wären verständlicher.\n- `while`-Schleifen zum Umrechnen von Minuten funktionieren, sind aber unnötig ineffizient bei großen Werten; eine arithmetische Lösung (Division/Modulo) wäre deutlich kompakter und besser lesbar.\n- `throw new IllegalArgumentException();` ohne Nachricht erschwert das Debugging; eine aussagekräftige Fehlermeldung macht sofort klar, welche Precondition verletzt wurde.\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: bosses\n\n### Correctness\n- `findCommonSuperiorWith(other)` überspringt den Fall, dass `other` selbst der gemeinsame Vorgesetzte ist, weil du in der inneren Schleife `b` zuerst auf `b.getBoss()` setzt und erst danach vergleichst; dadurch wird `a == other` nie erkannt.\n- `findCommonSuperiorWith(other)` gibt am Ende `a` zurück; zu diesem Zeitpunkt ist `a` aber immer `null` (weil die äußere Schleife bei `a == null` endet). Gefordert ist bei “kein gemeinsamer Vorgesetzter” explizit `null` – das trifft zwar zufällig zu, aber die Rückgabe ist logisch an den falschen Wert gebunden.\n\n### Suggestion\n- Überlege in `findCommonSuperiorWith`: Zu welchem Zeitpunkt solltest du `a` und `b` vergleichen, damit auch der Startknoten von `b` (also `other` selbst) berücksichtigt wird?\n- Achte darauf, was deine Schleifenvariable nach dem Loop garantiert (Schleifeninvariante): Wenn die Schleife endet, welchen Wert hat `a` dann sicher? Passt das zu der Rückgabe “kein gemeinsamer Vorgesetzter”?\n\n### Code Style\n- In `findCommonSuperiorWith` ist `return a;` am Ende verwirrend, weil `a` dort nur noch als Laufvariable dient; eine explizite `return null;` wäre klarer lesbar.\n- In `isSuperiorOf` veränderst du den Parameter `other` innerhalb der Methode; besser lesbar ist oft eine separate Laufvariable (z.B. `current`) statt den Eingabeparameter zu “verbrauchen”.\n\n\n# Exercise: smarthome\n\n### Correctness\n- `turnNextRoomBright`: In der `while`-Bedingung greifst du auf `rooms[i]` zu, bevor du geprüft hast, ob `i` noch im gültigen Bereich ist. Dadurch kann es bei bestimmten Zuständen zu einem Zugriff ausserhalb des Arrays kommen.\n- `nightMode`: Deine `findBedrooms()`-Methode liefert ein Array ohne `null`-Einträge zurück (genau passend gross). Damit erfüllst du zwar die Vorgabe, aber falls du diese Methode später anpasst und doch `null`-Einträge zulässt (wie explizit erlaubt), würde `nightMode` beim Iterieren darüber mit `bRoom.getLamps()` abstürzen. Im aktuellen Stand ist es ok, aber `nightMode` ist nicht robust gegenüber der laut Aufgabe erlaubten Rückgabeform.\n\n### Suggestion\n- `turnNextRoomBright`: Achte darauf, in der Schleife zuerst die Index-Grenze zu prüfen und erst danach `rooms[i]` zu verwenden. Überlege dir, wie du die Abbruchbedingung so formulierst, dass du nie mit einem ungültigen `i` auf das Array zugreifst.\n- `nightMode`: Überlege dir, wie du beim Durchlaufen des Bedroom-Arrays mit möglichen `null`-Einträgen umgehen würdest (die sind laut Spezifikation erlaubt). Eine einfache zusätzliche Prüfung beim Iterieren reicht meist schon.\n\n### Code Style\n- `findBedrooms()` baut das Array durch wiederholtes Kopieren in jedem Trefferfall auf; das ist unnötig teuer und macht den Code länger. Üblicher ist: einmal ein Array maximaler Grösse anlegen und mit einem separaten Index befüllen (genau so, wie es in der Aufgabenbeschreibung auch angedeutet ist).\n- `fullBright(Room room)` kann lesbarer werden, wenn du nicht in jeder Iteration `result = result && ...` schreibst, sondern die Logik klarer strukturierst (z.B. mit einer gut benannten Hilfsvariable oder einer Schleifenlogik, die den Zustand “nicht full bright” direkt ausdrückt, ohne `break/continue` zu verwenden).\n- In `nightMode` und `saveEnergy` verwendest du jeweils “erste Lampe” (`getLamps()[0]`) als “beliebige Lampe”. Das ist ok, aber es wäre lesbarer, wenn du diese Wahl (z.B. “firstLamp”) klar benennst oder als kleine Hilfsmethode kapselst.\n",
"status" : "SUCCESS"
}
}