{
"llm" : {
"feedback" : "# Exercise: parking\n\n### Correctness\n- `FlatRateCard.cost()` berechnet die Kosten nicht als fixe Monatskosten von 150 CHF, sondern macht sie davon abhängig, ob überhaupt geparkt wurde (bei `totalTime == 0` gibst du 0 zurück). Laut Aufgabenstellung sind es fixe Monatskosten.\n- Durch die aktuelle `FlatRateCard`-Logik kann der geforderte Gesamtumsatz von **156.75 CHF** je nach Testablauf/Reset-Verhalten verfehlt werden (weil die 150 CHF nicht zwingend immer eingerechnet werden).\n\n### Suggestion\n- Überlege dir bei `FlatRateCard`, was “fixe Monatskosten von 150 CHF” genau bedeutet: Soll dieser Betrag unabhängig von Parkzeit/Benutzung anfallen, und wenn ja, ab wann (z.B. immer pro Abrechnungsperiode), und wie passt das zu `calculateRevenueAndReset()`?\n\n### Code Style\n- In `ParkingSystem.java` ist der Import `javax.smartcardio.Card` unnötig/ungenutzt und sollte entfernt werden.\n- In `GroupCard` sollte `HOURLY_RATE` als Konstante/Instanzfeld klarer modelliert werden (z.B. `private final double hourlyRate;` statt veränderlichem Feld mit Großbuchstaben, die wie eine Konstante wirken).\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `LabyrinthApp` startest du die Schleife bei `level = 7`; damit werden nicht “die ersten Levels” (bzw. alle Levels) mit dem gewählten Algorithmus gespielt, obwohl die Aufgabe das Programm als “mehrere Levels” beschreibt und du den Algorithmus jeweils nur am Anfang setzen sollst.\n- Dein `BacktrackingAlgorithm` ist nicht allgemein, weil du in `navigate` eine feste Start-`direction` setzt (“Anpassen je nach Level”). Das widerspricht der Anforderung, einen allgemeinen Algorithmus zu bauen, der für alle diese Labyrinthe funktioniert.\n- In `BacktrackingAlgorithm` fehlt eine Mechanik, um bereits besuchte Zustände/Kreuzungen zu erkennen; dadurch kann dein rekursiver DFS in Labyrinthen mit Zyklen endlos laufen (oder so tief rekursieren, bis es kracht), statt garantiert fertig zu werden.\n\n### Suggestion\n- Schau in `LabyrinthApp`, ob die Level-Schleife wirklich alle Maps durchläuft (Startwert/Endbedingung) und ob das zu den Aufgaben-Teilschritten passt (erst Stupid, dann TryStraightFirst, dann Backtracking).\n- Überlege, wie du die Startorientierung der Figur herausfinden kannst, statt eine “Level-spezifische” Richtung zu setzen: Das `Figure`-Objekt liefert dir bereits Informationen zur aktuellen Orientierung.\n- Damit Backtracking “allgemein” wird, brauchst du eine Form von Gedächtnis: typischerweise markiert man mindestens Kombinationen aus `(row, col, dir)` oder merkt sich pro Zelle, aus welchen Richtungen man schon versucht hat weiterzugehen, damit man bei Zyklen nicht immer wieder dieselben Wege exploriert.\n\n### Code Style\n- In `BacktrackingAlgorithm` ist das Feld `direction` redundant/irreführend, weil die echte Richtung bereits im `Figure` steckt und du `direction` nirgends für Entscheidungen nutzt; das macht den Code schwerer verständlich.\n- Du hast sehr viel Template-Code (Figure/Labyrinth/LabyrinthGame/…) in der Abgabe dupliziert; üblicherweise gibst du nur die neu erstellten Klassen (Algorithmen) und die nötigen Änderungen an `LabyrinthApp` ab.\n- Der Kommentar `// TODO` in `LabyrinthApp` passt nicht mehr, wenn du die Stelle bereits korrekt befüllt hast.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `ModeButton` verwendest du `ch.trick17.gui.Color` und konstruierst ihn mit `new Color(1,1,1,50)` / `new Color(1,1,1,100)`. In dieser GUI-Bibliothek ist das sehr wahrscheinlich nicht die erwartete `Color`-Klasse bzw. nicht das passende Werteformat (typisch wären z. B. `gui.setColor(r,g,b)` oder andere Wertebereiche). Das kann zu Compilerfehlern oder falschen Farben führen.\n- In `ModeButton.draw(...)` rufst du `gui.setTextAlignCenter()` auf. Falls diese Methode in der verwendeten `Gui`-API nicht existiert (oder anders heisst), kompiliert das nicht.\n- In `ModeButton` ist `getInteractiveArea(Gui gui)` nicht mit `@Override` markiert. Wenn die Methodensignatur nicht exakt der von `Hoverable` entspricht (z. B. anderer Rückgabetyp/Package/Parameter), wird sie nicht als Override erkannt und Hover/Klick funktioniert dann nicht wie gefordert.\n\n### Suggestion\n- Schau im GUI-API nach, wie Farben gesetzt werden: Gibt es `gui.setColor(int r,int g,int b)` (wie in `SwissMap`) oder eine andere `Color`-Klasse? Passe Import und Wertebereich so an, dass es sicher kompiliert und sichtbar ist.\n- Prüfe in der `Gui`-Doku/Autocomplete, ob es wirklich `setTextAlignCenter()` gibt. Falls nicht, suche nach der korrekten Methode (oder lass das Alignment weg und positioniere den Text so, dass er optisch passt).\n- Vergleiche deine `getInteractiveArea`-Signatur exakt mit dem `Hoverable`-Interface (inkl. `Shape`-Typ aus dem richtigen Package). Wenn du `@Override` ergänzt und der Compiler meckert, zeigt er dir direkt, was an der Signatur nicht stimmt.\n\n3. Code Style:\n- `InteractiveArea` ist unbenutzt und `contains(...)` gibt immer `false` zurück; das wirkt wie toter/Experimentier-Code und sollte entfernt oder fertig implementiert werden.\n- In `ModeButton` sind die Imports sehr “wild” (`import ch.trick17.gui.Gui.*;`, `import ch.trick17.gui.component.*;`) und teils unnötig; importiere lieber nur konkret Benötigtes, das macht Fehler (v. a. bei `Color`) weniger wahrscheinlich.\n- In `City.draw(...)` rufst du `toGuiX/toGuiY` mehrfach hintereinander auf; speichere die Werte einmal in lokale Variablen, dann ist der Code lesbarer und effizienter.\n- In `SwissMapApp` deklarierst du `Component button = new ModeButton(map);` obwohl du direkt `gui.addComponent(new ModeButton(map));` machen könntest (weniger Boilerplate).\n\n\n# Exercise: visualizer\n\n### Correctness\n- Beim Prozessor-Datensatz ist die geforderte „effektive Rechengeschwindigkeit“ als `clockRate * cores` beschrieben; du verwendest stattdessen `Math.log10(cores * clockRateKhz)/1000`, wodurch sowohl Logarithmierung als auch Skalierung in die Daten wandern und nicht nur in die Achsendarstellung.\n- Beim Prozessor-Datensatz soll die Taktfrequenz in der Detailbeschreibung in kHz/MHz/GHz passend umgerechnet und formatiert werden; in `getDetails()` gibst du `clockRateKhz` aus, labelst es aber als `\"Mhz\"` und rechnest nicht um.\n- Beim Prozessor-Datensatz soll der Veröffentlichungsmonat aus Jahr und Monat zu einem Wert kombiniert werden; `year + month / 12.0` ist nicht eindeutig „Monat im Jahr“ (je nach Monat-Index 1..12 vs. 0..11 und ohne klare Abstandsdefinition). Das kann die zeitliche Abfolge/Abstände leicht verfälschen.\n\n### Suggestion\n- Überlege dir, ob die Logarithmierung wirklich in `Processor.getY()` passieren sollte, oder ob `getY()` lieber die „Rohgrösse“ (clockRate * cores) liefert und die log-Skalierung an einer Stelle passiert, die die Achse betrifft (so wie in der Aufgabenbeschreibung angedeutet).\n- Prüfe für `Processor.getDetails()`: Welche Einheit steckt in `clockRateKhz` wirklich drin, und welche Umrechnung brauchst du für kHz/MHz/GHz? Achte auch darauf, dass MHz/kHz als ganze Zahlen und GHz mit Dezimalstelle angezeigt werden sollen.\n- Bei `Processor.getX()`: Kläre zuerst, ob `month` im Datensatz 1–12 ist, und wähle dann eine Kombination, die wirklich „Monatsschritte“ gleichmässig abbildet (und nicht z.B. Januar zu nahe bei Jahr+0 liegt bzw. Dezember nicht exakt am Jahresende). Teste das, indem du dir ein paar (Jahr, Monat)-Paare aus dem CSV manuell ausrechnest.\n\n### Code Style\n- In `Visualizer` sind `DUMMY_DOUBLE` und `DUMMY_STRING` jetzt unbenutzt und können entfernt werden, sobald du sicher bist, dass alles migriert ist.\n- In `Movie.getX()` steht der Kommentar `// Beispiel`, der wie ein temporärer Hinweis wirkt; den würde ich entfernen, wenn die Implementierung final ist.\n- `Country.getDetails()` mischt Kommas und Zeilenumbrüche etwas inkonsistent; wenn du schon `\\n` verwendest, könntest du die Detailzeilen konsequent strukturieren (Lesbarkeit im Hover-Overlay).\n",
"status" : "SUCCESS"
}
}