{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- In `GroupCard` ist `HOURLY_RATE` als `static` deklariert. Dadurch teilen sich alle `GroupCard`-Instanzen denselben Tarif und die letzte erstellte `GroupCard` überschreibt den Tarif für alle anderen. Das verletzt die Idee, dass der Tarif pro Karte von der Personenanzahl (Konstruktor-Parameter) abhängt.\n- In `GroupCard` wird bei `i <= 0` kein Tarif gesetzt (bleibt 0.0), obwohl die Tarif-Tabelle nur für sinnvolle Personenzahlen gilt; damit wäre Parken für 0/negative Personen kostenlos statt “nicht erlaubt”/ungültig (je nachdem, wie du es interpretieren sollst).\n- In `FlatRateCard` ist die Monatskosten-Logik zwar konstant 150 CHF, aber du sammelst trotzdem `totalTime` und setzt es zurück. Falls das Abo im Rahmen dieser Aufgabe trotzdem die Parkzeit “vergessen” soll, ist das ok – aber wenn der Test/Beispiel erwartet, dass `park()`/`reset()` keine Rolle spielen, ist das unnötig und kann zu Missverständnissen führen.\n\n### Suggestion\n- Überlege bei `GroupCard`, ob der Stundentarif wirklich eine Klassenvariable sein sollte oder ob jede Karte ihren eigenen Tarif “speichern” muss, der sich aus der Personenanzahl ergibt.\n- Prüfe, welche Eingaben für die Personenanzahl laut Aufgabenstellung überhaupt zulässig sind (insbesondere der untere Rand) und behandle ungültige Werte konsequent wie den Fall “mehr als 20”.\n- Schau dir bei `FlatRateCard` an, ob du überhaupt internen Zustand (`totalTime`) brauchst, wenn `cost()` immer gleich ist, und was `reset()` in so einem Fall sinnvollerweise tun sollte.\n\n3. Code Style:\n- `GroupCard`: `HOURLY_RATE` sollte als Konstante oder Instanzfeld benannt/strukturiert werden; aktuell ist es `static` und zudem nicht `final`, was schnell zu schwer nachvollziehbarem Verhalten führt.\n- `GroupCard`: `PersonenAnzahl` wird gespeichert, aber danach nie verwendet; entweder verwenden (z.B. für Debug/Validierung) oder weglassen.\n- Einheitliche Benennung: Mische nicht deutsch/englisch in Feldnamen (`PersonenAnzahl` vs. `HOURLY_RATE`), das erschwert Wartung/Lesbarkeit.\n- `FlatRateCard`: `totalTime` ist aktuell ungenutzt (außer zum Hochzählen/resetten), das ist toter Zustand und lenkt ab.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `TryStraightFirst` machst du bei `pathToTheLeft()`/`pathToTheRight()` nur ein `turnLeft()`/`turnRight()`, aber keinen Schritt nach vorne; die Aufgabenbeschreibung verlangt, dass in dem Fall auch tatsächlich gegangen wird.\n- Dein `BacktrackingAlgorithm` kann in Endlosschleifen geraten, weil du keine bereits besuchten Zustände/Abzweigungen markierst (dadurch kannst du immer wieder in denselben Zyklus zurücklaufen, obwohl du “zurückgehst”).\n- In `BacktrackingAlgorithm` ist die “Rückwärts”-Orientierung nach dem Backtracking nicht konsistent: `rückwärtsLeft` und `rückwärtsRight` stellen nach dem Zurückgehen nicht wieder die gleiche Blickrichtung her, die du vor dem Erkunden des linken/rechten Pfads hattest; dadurch testest du danach nicht mehr die “richtigen” Richtungen relativ zur ursprünglichen Kreuzung.\n- Du hast in `LabyrinthApp` die vorgegebenen `MAPS` durch eigene Maps ersetzt; damit erfüllst du nicht mehr die Anforderung, die Levels aus der Vorlage (v.a. die letzten) zu lösen.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir, was nach einem Turn passieren muss, damit die Figur den neuen Pfad tatsächlich ausprobiert; vergleiche das mit deiner `pathAhead()`-Behandlung.\n- Für Backtracking ohne Memory: Backtracking funktioniert in Labyrinthen mit Schleifen erst zuverlässig, wenn du verhindern kannst, dass du denselben Zustand erneut explorierst. Ein “Zustand” ist typischerweise mehr als nur `(row,col)` (denke auch an `dir()`).\n- Für die Rückwärts-Funktionen: Prüfe jeweils Schritt für Schritt, welche Blickrichtung die Figur **vor** dem Abbiegen hatte, welche nach `turnLeft()/turnRight()` gilt, und welche du nach dem “Zurücklaufen” wieder herstellen musst, damit du an der Kreuzung in derselben Orientierung weitermachst.\n- Für `LabyrinthApp`: Stelle die originale `MAPS`-Konstante wieder her und teste deinen Algorithmus auf genau diesen Levels; eigene Testmaps sind gut zum Debuggen, aber am Ende muss es mit den gegebenen funktionieren.\n\n### Code Style\n- Methoden- und Variablennamen wie `rückwärtsLeft`/`rückwärtsRight` enthalten Umlaute; das kann je nach Tooling/Encoding unnötige Probleme machen. Besser konsequent ASCII verwenden.\n- `navigateRec` ist `public`, wird aber nur intern verwendet; das schreit nach `private`.\n- `BacktrackingAlgorithmWithMemory` ist leer und unbenutzt – entweder entfernen oder wirklich implementieren.\n- In `LabyrinthApp` sind große Code-Blöcke auskommentiert; besser die Original-Maps unverändert lassen und für eigene Tests separate Konstanten/Dateien verwenden.\n\n\n# Exercise: swissmap\n\n### Correctness\n- `SwissMapApp`: Die `main`-Methode hat die Signatur `void main()`. So wird sie nicht als Java-Startpunkt erkannt (es braucht eine echte `public static void main(String[] args)`-Methode).\n- `Mountain.draw`: Du verwendest einen absoluten Dateipfad zu einem Bild auf deinem Computer. Das funktioniert nicht mehr, sobald das Programm auf einem anderen Rechner / als JAR läuft; gefordert ist die Verwendung der Ressourcen-Pfade (wie bei `SwissMap`/deinem `Lake`).\n- `City.getInteractiveArea` / `Lake.getInteractiveArea` / `Mountain.getInteractiveArea`: Dein `Rectangle` startet bei `(coord.toGuiX, coord.toGuiY)` und geht dann nach rechts/unten. Damit liegt der interaktive Bereich nicht um das gezeichnete Symbol zentriert (bei der City liegt der Punkt sogar teilweise ausserhalb der Area). Das führt dazu, dass Hover nicht dort auslöst, wo das Objekt sichtbar ist.\n\n### Suggestion\n- Schau dir an, wie in Java eine Applikation gestartet wird (Entry-Point) und passe die Methodensignatur in `SwissMapApp` entsprechend an.\n- Lade Bilder immer über den Ressourcen-Namen relativ zum `resources`-Ordner (ähnlich wie `\"swissmap/Switzerland_map.png\"`), nicht über einen lokalen Pfad von deinem Dateisystem.\n- Überlege dir bei `getInteractiveArea`, wo dein Objekt tatsächlich gezeichnet wird (z.B. City: Mittelpunkt bei `toGuiX/toGuiY` mit Radius 3; Lake/Mountain: Bild hat eine Breite/Höhe). Definiere das Rectangle so, dass es diese gezeichnete Fläche abdeckt bzw. sinnvoll umschliesst (typisch: links/oben um eine halbe Breite/Höhe verschieben).\n\n### Code Style\n- Unnötige Imports: In `City` sind z.B. `java.awt.*` unbenutzt; in `ModeButton` sind u.a. `javax.swing.*`, `java.awt.*` und doppelte Imports (`Rectangle`, `Shape`) unnötig.\n- Sichtbarkeiten/Benennung: In `ModeButton` sind Felder wie `SwissMap map`, `boolean pressed`, `String text` package-private; mach sie konsistent `private` (Kapselung).\n- Kommentare wie „Muss implementiert werden…“ wiederholen im Wesentlichen Java-Grundlagen; lieber knapp halten oder weglassen, wenn sie keinen Mehrwert für den Code liefern.\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 als _y_-Wert die effektive Rechengeschwindigkeit verwendet werden (Taktfrequenz × Cores) und die logarithmische Darstellung soll über eine logarithmische _y_-Achse erfolgen; du berechnest stattdessen bereits in `Processor.getY()` den Logarithmus, wodurch die Achse nicht „logarithmisch“ ist, sondern die Daten transformiert sind.\n- Beim Prozessor-Datensatz soll die Taktfrequenz in der Detailbeschreibung in eine geeignete Einheit (kHz/MHz/GHz) umgerechnet und entsprechend formatiert werden; in `Processor.getText()` gibst du `clockRateKhz` unverändert aus.\n\n### Suggestion\n- Ergänze bei jeder Methode im `DataPoint`-Interface eine kurze Javadoc-Beschreibung, die klar macht, was der Visualizer damit macht (z.B. was auf der x-/y-Achse landet, was als Titel im Hover erscheint, wie Zeilenumbrüche behandelt werden, was „group/legend“ bedeutet).\n- Überlege dir beim Prozessor-Plot, an welcher Stelle die „Logarithmus-Idee“ hingehört: Entweder bleibt `getY()` bei der „echten“ Geschwindigkeit und der Visualizer skaliert/log-transformiert beim Zeichnen, oder du entscheidest dich bewusst für transformierte Werte – aber dann passt die Anforderung „logarithmische y-Achse“ nicht mehr wörtlich.\n- Baue die Frequenzanzeige so um, dass aus `clockRateKhz` je nach Größenordnung kHz/MHz/GHz wird und die Formatierung (Ganzzahl vs. Dezimalzahl bei GHz) zur Aufgabenbeschreibung passt.\n\n### Code Style\n- Die Konstanten `DUMMY_DOUBLE` und `DUMMY_STRING` in `Visualizer` sind jetzt unbenutzt und können entfernt werden, damit der Code nicht nach „halbfertig“ aussieht.\n- Interface-Methodennamen wie `getLegend()`, `getText()`, `getHighlight()` sind etwas uneindeutig; sprechendere Namen (z.B. „group“, „label/title“, „details“) würden die Schnittstelle klarer machen (musst du natürlich konsistent im Visualizer und den Implementierungen halten).\n- In `Movie.getText()` wäre eine konsistentere Formatierung (z.B. Einheiten/Zeilenumbrüche wie bei den anderen Datensätzen) leichter lesbar; aktuell mischst du einmal `\\n` und einmal „Budget: …“ ohne Einheit/Formatierung.\n",
"status" : "SUCCESS"
}
}