{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `ParkingSystemExample` ist zusätzlicher Code mit `List.of(...)` und `colors.add(...)`, der beim Ausführen zu einer `UnsupportedOperationException` führt und damit das geforderte Programmverhalten (Umsatz ausgeben) verhindert.\n- Die Ausgabe in `ParkingSystemExample` entspricht nicht der Anforderung: Es soll beim Ausführen ein Gesamtumsatz von **156.75 CHF** angezeigt werden (dein Code druckt zusätzlich noch etwas bzw. crasht vorher).\n- `GroupCard` und `FlatRateCard` haben keinen `public` Konstruktor; falls die Tests/Beispielcode aus einem anderen Package zugreifen, ist `new GroupCard(15)`/`new FlatRateCard()` so nicht sichtbar.\n- `FlatRateCard.cost()` liefert immer 150, unabhängig davon, ob bereits abgerechnet wurde und unabhängig von `reset()`; je nach Erwartung des Systems kann das zu mehrfacher Verrechnung des Monatsbetrags führen, wenn `calculateRevenueAndReset()` mehr als einmal aufgerufen wird.\n\n### Suggestion\n- Entferne den zusätzlichen `List`-Teil komplett oder stelle sicher, dass er nicht ausgeführt wird; `List.of(...)` ist unveränderlich, deshalb schlägt `add(...)` fehl.\n- Prüfe, dass dein Programm genau den erwarteten Ablauf macht: Karten registrieren, parken, `calculateRevenueAndReset()`, dann genau den Gesamtumsatz ausgeben (ohne weitere Ausgaben/Fehler).\n- Mach die Konstruktoren von `GroupCard` (und ggf. `FlatRateCard`) `public`, damit sie sicher von außen instanziiert werden können.\n- Überlege bei der `FlatRateCard`, was `reset()` semantisch bedeuten soll: Soll nach dem Reset der Monatsbetrag nochmals berechnet werden dürfen oder nicht? Falls nicht, brauchst du einen internen Zustand, der verhindert, dass `cost()` nach dem Abrechnen nochmals 150 zurückgibt.\n\n### Code Style\n- In `GroupCard` sollten Felder wie `noOfPeople`, `HOURLY_RATE`, `totalTime` gekapselt sein (`private`) und Konstanten typischerweise als `private final`/`static final` benannt werden (z.B. `hourlyRate` statt `HOURLY_RATE`, wenn es keine Konstante ist).\n- `FlatRateCard.park()`/`reset()` sind leer – das ist ok, aber ein kurzer Kommentar zur Intention (Abo ignoriert Parkzeit) würde die Lesbarkeit erhöhen.\n- Entferne unbenutzte Imports/Code: `import java.util.List;` und der gesamte Farben-Block sind themenfremd und stören die Übungsaufgabe.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- Dein `BacktrackingAlgorithm` ist inhaltlich kein Backtracking, sondern eine feste Links-/Geradeaus-/Rechts-Priorität (Wall-Following). Damit erfüllst du die Anforderung „allgemeiner Algorithmus, der für alle diese Labyrinthe funktioniert“ nicht zwingend – solche Strategien können in bestimmten Labyrinthen in Schleifen hängen bleiben oder das Ziel nie erreichen.\n- Beim geforderten Backtracking-Ansatz fehlt bei dir jegliche Zustandsverwaltung (z.B. gemerkte Kreuzungen/Entscheidungen oder besuchte Kanten/Felder). Ohne das ist es kein Backtracking im Sinne der Aufgabe, weil du nicht systematisch alternative Wege ausprobierst, wenn ein Ast eine Sackgasse ist.\n\n### Suggestion\n- Überlege dir, was „backtracking“ im Labyrinth konkret bedeutet: Wenn du in eine Sackgasse läufst oder alle Ausgänge eines Knotens schon ausprobiert wurden, musst du gezielt zu einer früheren Verzweigung zurück und dort den *nächsten* noch nicht getesteten Ausgang wählen.\n- Dafür brauchst du irgendeine Form von „Gedächtnis“: z.B. eine Struktur, die Entscheidungen speichert (an welcher Position/Orientierung bist du abgebogen?) und/oder markiert, welche Wege von einem Punkt schon probiert wurden.\n- Teste deinen Ansatz gedanklich an einem Labyrinth mit einer Schleife (Ring) ohne „Außenwand“-Kontakt zum Ziel: Eine reine Linksregel kann ewig im Kreis laufen. Frag dich: Woran würdest du im Code erkennen, dass du gerade in einem Kreis bist, und wie würdest du dann anders entscheiden?\n\n### Code Style\n- In deinen Algorithmus-Klassen fehlen `@Override`-Annotationen bei `navigate(...)` (hilft dem Compiler und macht die Implementierung klarer).\n- Du hast sehr viel Template-/Framework-Code (Figure/Labyrinth/LabyrinthGame/etc.) in der Abgabe mit drin; normalerweise reicht es, nur die von dir erstellten/angepassten Klassen abzugeben (je nach Abgabevorgaben).\n- In `BacktrackingAlgorithm` und `TryStraightFirst` ist das „Umdrehen“ doppelt als `turnRight(); turnRight();` geschrieben; eine kleine Hilfsmethode (z.B. `turnAround`) würde Duplikate reduzieren und Lesbarkeit erhöhen.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist `main()` nicht als Java-Entry-Point deklariert (es fehlt `public static void main(String[] args)`), dadurch startet das Programm i. d. R. nicht wie gefordert über die Main-Methode.\n- In `Coordinate.toGuiX/toGuiY` greifst du auf `SwissMap.TOP_LEFT.east` bzw. `.north` zu, obwohl diese Felder in `Coordinate` `private` sind; das kompiliert so nicht.\n\n### Suggestion\n- Schau dir die Signatur an, die Java für den Programmstart erwartet, und passe die `main`-Methode in `SwissMapApp` entsprechend an.\n- Verwende in `Coordinate` für `TOP_LEFT` nicht den direkten Feldzugriff auf `east/north`, sondern den Weg, der mit der Kapselung kompatibel ist (z. B. über vorhandene Zugriffsmethoden oder indem du die nötigen Werte anders verfügbar machst).\n\n### Code Style\n- `volatile` für die Hover-Flags/Farben ist hier sehr wahrscheinlich unnötig; das macht den Code schwerer lesbar, ohne dass du typischerweise einen Threading-Vorteil bekommst.\n- In `ModeButton` sind `color1/color2` als veränderliche Zustände etwas verwirrend benannt (sie sind je nach Modus/Vover-Effekt nicht “erste/zweite” Farbe, sondern tauschen Rollen); sprechendere Namen würden die Logik leichter nachvollziehbar machen.\n- Viele Magic Numbers (z. B. 5, 10, 17, 34, 0.5, Offsets für Text) sind “verstreut”; als Konstanten benannt wäre das einfacher zu warten/anzupassen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Im `DataPoint`-Interface fehlen die geforderten Javadoc-Kommentare zur Dokumentation des erwarteten Verhaltens der Methoden.\n- Beim Prozessor-Datensatz soll für die „effektive Rechengeschwindigkeit“ laut Aufgabe **Taktfrequenz × Cores** verwendet werden und **die y-Achse** soll logarithmisch sein; du gibst aber in `Processor.getY()` bereits den Log-Wert zurück. Dadurch wird im Tooltip/Highlight nicht mehr die effektive Geschwindigkeit visualisiert, sondern deren Logarithmus.\n- Die Detailbeschreibung beim Prozessor soll die Taktfrequenz je nach Einheit so formatieren, dass kHz/MHz als ganze Zahlen und GHz als Kommazahlen erscheinen (z. B. „800 MHz“ vs „2.5 GHz“). Deine Ausgabe hängt die Einheit ohne Leerzeichen an (`\"GHz\"`, `\"MHz\"`, `\"kHz\"`) und bei GHz wird die Zahl unformatiert ausgegeben (potenziell viele Dezimalstellen).\n\n### Suggestion\n- Ergänze zu jeder Methode im `DataPoint`-Interface kurz, was sie liefert (z. B. Bedeutung für x/y-Achse, Gruppierung für Farben, Text im Hover) und ob `null` erlaubt ist.\n- Überlege beim Prozessor-Datensatz, wo die Logarithmierung „hingehört“: Die Aufgabe trennt zwischen „Wert“ (clockRate × cores) und „Darstellung“ (logarithmische y-Achse). Prüfe, ob du beides in `getY()` vermischst.\n- Für die Prozessor-Taktfrequenz im Tooltip: Achte darauf, dass du die gewünschte Einheit **mit passender Rundung/Formatierung** und **mit Leerzeichen** ausgibst (und GHz wirklich mit einer sinnvoll begrenzten Anzahl Dezimalstellen).\n\n### Code Style\n- `DataPoint` importiert `ch.trick17.gui.component.Hoverable`, wird aber nirgends verwendet → entfernen.\n- Im Interface `DataPoint` ist `toString()` explizit deklariert; das ist ungewöhnlich, weil `toString()` bereits von `Object` kommt. Lesbarer wäre eine klar benannte Methode für den Detailtext (z. B. „description“/„details“) statt `toString()` als Teil der Schnittstelle zu verlangen.\n- In `Movie.toString()` rechnest du Budget in Millionen um, aber ohne Formatierung/Einheitentrennung (z. B. fehlende Tausendertrennzeichen, Rundung). Das ist nicht falsch, aber die Lesbarkeit im Tooltip leidet.\n",
"status" : "SUCCESS"
}
}