{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `GroupCard`: Laut Aufgabenstellung sind „mehr als 20“ Personen **nicht erlaubt** (also > 20). Du prüfst das erst in `cost()`. Damit kann man eine ungültige Karte registrieren und erst viel später (beim Umsatzberechnen) knallt es; das verletzt die Idee „nicht erlaubt“ für diesen Kartentyp.\n- `FlatRateCard`: Du führst `totalTime` mit und erhöhst es in `park()`, obwohl es für die Kosten nie verwendet wird. Das ist fachlich inkonsistent zur Anforderung „fixe Monatskosten“ (bei einer Flatrate sollte Parkdauer keinen Einfluss haben und i.d.R. auch nicht „gespeichert“ werden müssen).\n\n### Suggestion\n- Überlege bei der `GroupCard`, **wann** du die Personenanzahl validieren möchtest, damit „nicht erlaubt“ wirklich schon beim Erstellen/Registrieren der Karte gilt und nicht erst beim späteren Aufruf von `cost()`.\n- Bei der `FlatRateCard`: Überlege, ob du überhaupt einen Zustand wie `totalTime` brauchst, wenn `cost()` immer gleich ist, und was dann `park()`/`reset()` sinnvollerweise tun sollten, damit das Verhalten zur „fixen Monatskosten“-Idee passt.\n\n### Code Style\n- `FlatRateCard`: `totalTime` ist aktuell effektiv ungenutzt (hat keinen Einfluss auf `cost()`), das macht den Code unnötig verwirrend; entweder sinnvoll verwenden oder entfernen.\n- `GroupCard`: Die Fehlermeldung `\"Has to be less than 20 people.\"` passt nicht ganz zu deiner Bedingung (`> 20` ist verboten, `20` ist erlaubt). Formuliere die Message konsistent zur Regel („more than 20 not allowed“ / „max. 20“).\n- In `GroupCard.cost()` heißt die Variable `cost`, wodurch Methode und Variable denselben Namen tragen (legal, aber schwerer zu lesen). Ein Name wie `hourlyRate` wäre klarer.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- `TryStraightFirst` erfüllt die geforderte Logik nicht: Wenn vorne frei ist, soll **ein Schritt nach vorne** gemacht werden; wenn nicht, soll **links oder rechts versucht** werden und **nur wenn gar nichts geht** soll die Figur **rechts um kehrt** machen. In deinem Code wird bei „links frei“ nur gedreht (ohne vorwärts zu gehen), bei „sonst“ immer nach rechts gedreht (auch wenn rechts gar kein Pfad ist) und die 180°-Wende kommt nirgends vor.\n- `TryStraightFirst` kann dadurch `moveForward()` aufrufen, obwohl `pathAhead()` nach dem Drehen nicht geprüft wurde (z.B. im `else`-Fall), was im Spiel zu `GameOver(\"Pfad verlassen!\")` führen kann.\n- `BacktrackingAlgorithm` ist kein vollständiges Backtracking für alle Labyrinthe: Du merkst dir keine besuchten Positionen/Abzweigungen, dadurch kannst du in Zyklen geraten bzw. denselben Bereich immer wieder erneut durchsuchen und evtl. nie terminieren.\n- `BacktrackingAlgorithm`: Beim Zurückgehen nach einem „links“-Versuch stellst du die Orientierung nicht zuverlässig wieder her. Du gehst zwar zurück, aber am Ende fehlt eine Drehung, damit die Figur wieder in der ursprünglichen Richtung steht, bevor der nächste Zweig ausprobiert wird.\n- In `LabyrinthApp` verwendest du eine fixe Algorithmus-Auswahl (`currAlgo = 2`). Für Teil (b) war explizit gefordert, in der `main`-Methode den `StupidAlgorithm` durch `TryStraightFirst` zu ersetzen, um die ersten vier Levels zu schaffen; mit deiner aktuellen Einstellung wird das nicht demonstriert.\n\n### Suggestion\n- Für `TryStraightFirst`: Bau die Schleife genau nach der beschriebenen Priorität auf („wenn vorne: vorwärts; sonst wenn links: erst drehen, dann vorwärts; sonst wenn rechts: erst drehen, dann vorwärts; sonst: zweimal rechts drehen (U-Turn) und dann vorwärts“). Achte darauf, dass du nach jeder Drehentscheidung auch wirklich einen Schritt machst (oder erneut prüfst), damit die Figur nicht nur rotiert.\n- Vermeide in `TryStraightFirst` den „immer nach rechts drehen“-Fallback ohne Pfadprüfung: Überleg dir, wie du sicherstellst, dass `moveForward()` nur passiert, wenn vor dir wirklich ein Pfad ist (insbesondere nach Drehungen).\n- Für echtes Backtracking: Du brauchst ein Konzept von „Zustand“, den du schon besucht hast (z.B. Kombination aus `(row, col, dir)` oder mindestens `(row, col)`), sonst kann die Suche in Schleifen hängen. Denk an eine Datenstruktur, in der du markierst, welche Knoten/Abzweigungen bereits vollständig abgearbeitet wurden.\n- Für `BacktrackingAlgorithm` (Orientierung): Überlege dir eine Invariante wie „Wenn `navigate` zurückkehrt (ohne Ziel), steht die Figur wieder exakt so wie beim Eintritt in die Methode“. Dann kannst du nach jedem erfolglosen Versuch systematisch „undo“ machen: zurücklaufen und die Drehungen so rückgängig machen, dass die Ausgangsrichtung wieder stimmt.\n\n### Code Style\n- `TryStraightFirst` und `BacktrackingAlgorithm` nutzen Rekursion als „Schleife“. Für diese Aufgabe ist eine iterative `while`-Schleife oft übersichtlicher (und vermeidet sehr tiefe Rekursion/Stackoverflow bei grösseren Labyrinthen).\n- In `LabyrinthApp` ist `import java.util.ArrayList;` nur für die Algorithmus-Liste da; das wirkt für die Aufgabe unnötig komplex. Eine direkte Zuweisung zu `NaviAlgorithm navi = new ...` wäre klarer.\n- In `BacktrackingAlgorithm` wiederholst du die Sequenz „zweimal drehen + moveForward + zweimal drehen“ mehrfach. Das schreit nach einer kleinen Hilfsmethode (z.B. „zurück zum vorherigen Feld gehen und Orientierung wiederherstellen“), damit du weniger Copy/Paste hast und weniger leicht Drehfehler passieren.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode als `void main()` deklariert; so wird sie als Einstiegspunkt in Java normalerweise nicht gefunden (üblich ist eine `public static void main(String[] args)`-Signatur).\n- In `Lake.draw` und `Mountain.draw` verwendest du Bildpfade wie `\"src/main/resources/...\"`; die GUI lädt Ressourcen typischerweise relativ zum Classpath (wie bei der SwissMap mit `\"swissmap/...\"`). Mit den aktuellen Pfaden werden die Bilder je nach Umgebung sehr wahrscheinlich nicht gefunden.\n- In `ModeButton.draw` zeichnest du das Rechteck mit Breite `55`, aber in `getInteractiveArea` ist das Rechteck `80` breit; dadurch ist der klick-/hover-bare Bereich nicht deckungsgleich mit dem sichtbaren Button.\n\n### Suggestion\n- Schau dir an, welche Methodensignatur Java als Programmstart erwartet, und passe die `main`-Methode entsprechend an (Stichwort: `static` und Parameterliste).\n- Orientiere dich bei den Lake/Mountain-Images an der Art, wie `SwissMap` ihr Hintergrundbild lädt (Ressourcenpfad ohne `src/main/resources`). Teste, ob die Dateien im gleichen Ressourcen-Ordner liegen und wie sie zur Laufzeit adressiert werden müssen.\n- Verwende für Button-Zeichnung und `getInteractiveArea` gemeinsame Konstanten/Attribute (x, y, width, height), damit sichtbarer Button und interaktive Fläche identisch sind.\n\n### Code Style\n- In `City.draw` überschattest du das Feld `name` mit einer lokalen Variable `String name = getName();`; das ist verwirrend – entweder direkt `name` verwenden oder die lokale Variable anders nennen.\n- In `getInteractiveArea` (City/Lake/Mountain/ModeButton) kannst du direkt `return new Rectangle(...);` schreiben statt erst eine Variable `rec` zu erstellen.\n- In `ModeButton` ist `TOP_LEFT` als eigene Konstante doppelt vorhanden, obwohl es bereits `SwissMap.TOP_LEFT` gibt; das erhöht Redundanz und das Risiko, dass Werte auseinanderlaufen.\n- `ModeButton` speichert `map` unveränderlich – dann wäre `private final SwissMap map;` passender.\n- Leere Methoden wie `onRightClick`, `onMouseEnter`, `onMouseExit` könntest du zumindest kurz kommentieren (z.B. “intentionally left blank”), damit klar ist, dass es absichtlich leer ist.\n\n\n# Exercise: visualizer\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}