{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Deine `toString()`-Ausgabe in `Task` entspricht nicht dem im Beispiel gezeigten Format: dort steht ein Häkchen `✓` (oder nichts) vor `[` und es gibt ein Leerzeichen vor der ID-Zeile; außerdem wird kein `[X]`/`[ ]` gezeigt.\n- Die Fehlermeldung bei ungültiger ID soll exakt `\"Task with ID XX not found\"` sein; bei dir steht `\"Task with ID \" + id + \" not found\"`.\n\n### Suggestion\n- Vergleiche die geforderte Konsolen-Ausgabe Zeichen für Zeichen mit deiner `toString()` (inkl. Leerzeichen/Einrückung und dem Symbol für „done“). Überlege, welche Teile in `toString()` rein müssen, damit `IO.println(task);` genau dieses Format erzeugt.\n- Schau dir die Aufgabenbeschreibung zur Fehlermeldung an: wenn dort ein fixer Text vorgegeben ist, lohnt es sich, ihn genau so zu übernehmen (auch wenn es „komisch“ wirkt, dass `XX` nicht durch die ID ersetzt wird).\n\n### Code Style\n- `import ch.fhnw.prog1.exercise.todo.Task;` ist in `ToDoApp` redundant, weil `Task` im gleichen Package liegt.\n- `public Task[] tasks = new Task[100];` kann (falls nicht anders verlangt) eher `private` sein, damit der interne Zustand nicht von außen verändert wird.\n- In `listTasks` iterierst du immer über `tasks.length` (100). Funktional ok, aber für Lesbarkeit/Performance wäre es oft klarer, nur über den tatsächlich genutzten Bereich zu iterieren (z. B. indem man mitzählt, wie viele Tasks belegt sind).\n\n\n# Exercise: energymeter\n\n### Correctness\n- Deine Methoden und der Konstruktor sind als `public` deklariert, während im vorgegebenen Gerüst/Beispiel keine `public`-Sichtbarkeit vorgesehen ist (package-private). Falls die Unit-Tests im selben Package auf package-private Signaturen ausgelegt sind, passt deine Signatur nicht zur erwarteten.\n- Der Konstruktor wirft bei negativer Kapazität eine `IllegalArgumentException` mit Message; wenn die Tests genau auf den Exception-Typ ohne Message bzw. auf eine bestimmte Message prüfen, kann das fehlschlagen.\n\n### Suggestion\n- Schau dir an, ob in der Aufgabenbeschreibung/Tests explizit package-private erwartet wird (kein `public`). Passe dann die Sichtbarkeiten von Attributen/Konstruktor/Methoden entsprechend an.\n- Wenn du eine Exception wirfst: prüfe, ob die Tests nur den Typ testen oder auch die Message. Im Zweifelsfall die einfachste Form der Exception verwenden.\n\n### Code Style\n- Du hast an mehreren Stellen `if/else`-Blöcke, die denselben Effekt wie ein “Clamping” auf `[0, capacity]` haben; das ist okay, aber lässt sich oft knapper und gleichmäßiger ausdrücken (weniger Duplication).\n- Die Exception-Message ist deutsch, während der Rest eher neutral ist; konsistente Messages (oder keine) machen Tests/Codebasis oft robuster.\n\n\n# Exercise: pong\n\n### Correctness\n- Es fehlen die Klassen `Player` und `Ball` (inkl. der geforderten Attribute wie Position, Balkenlänge/Punkte bzw. Geschwindigkeit).\n- In `PongGame` werden keine zwei `Player`-Objekte und kein `Ball`-Objekt erstellt/initialisiert (Ball in der Mitte, zufällige Startgeschwindigkeit).\n- In der Spielschleife wird weder die Bewegung der Balken per Tastatur noch die Bewegung des Balls umgesetzt.\n- Kollisionen mit oberen/unteren Wänden (Ball abprallen, Spieler im Feld halten) sind nicht implementiert.\n- Kollisionen Ball↔Balken sowie Seitenwand-Treffer mit Punktevergabe und Ball-Reset fehlen.\n- Anzeige von Spielern/Ball/Punktestand erfolgt nicht anhand der Objektzustände, sondern nur über die statischen Beispiel-Zeichnungen.\n- Erweiterung auf mehrere Bälle (Ball-Array, periodisch neue Bälle, Entfernen beim Verlassen) ist nicht umgesetzt.\n\n### Suggestion\n- Fang mit minimalen Datenklassen an: Überlege dir, welche Felder ein `Player` und ein `Ball` unbedingt brauchen, damit du zeichnen und bewegen kannst.\n- Initialisierung: Setz die Spieler sinnvoll links/rechts mittig und den Ball exakt in die Feldmitte; für die zufällige Geschwindigkeit kannst du Betrag und Vorzeichen getrennt bestimmen.\n- Bewegung: Nutze die Tastaturabfragen nicht nur als `boolean`, sondern leite daraus pro Frame eine Positionsänderung ab (hoch/runter) und aktualisiere beim Ball `px/py` anhand `vx/vy`.\n- Wände: Prüfe nach dem Bewegen, ob der Ball oben/unten “hinaus” ragt, und korrigiere Position + invertiere nur `vy`; bei den Spielern clampst du `py` so, dass sie im Fenster bleiben.\n- Schläger-Kollision: Denk in einfachen Rechteck-Überlappungen (Ball als Kreis kannst du zunächst als Bounding-Box behandeln); beim Treffer soll sich hauptsächlich `vx` umdrehen und der Ball aus dem Schläger “herausgeschoben” werden, damit er nicht mehrfach in einem Frame punktet/kollidiert.\n- Seitenwände & Punkte: Wenn der Ball links/rechts rausgeht, erhöhe den Punktestand des anderen Spielers und setze den Ball wieder in die Mitte (mit neuer zufälliger Geschwindigkeit).\n- Mehrere Bälle: Plane eine Struktur mit “aktiven” Bällen im Array (z.B. ein Zähler für die Anzahl aktiver Einträge), damit Hinzufügen/Entfernen ohne teures Verschieben möglich ist; zusätzlich brauchst du einen Timer/Frame-Counter für “alle 1–2 Sekunden”.\n\n### Code Style\n- Viele `TODO`/Kommentar-Blöcke sind noch unverändert; sobald du implementierst, entferne die Platzhalter und ersetze sie durch sprechende Variablennamen/Methoden.\n- Die Variablen `p1Up` und `p2Up` werden aktuell nicht verwendet; entweder einbauen (für Bewegung) oder weglassen, um Warnungen zu vermeiden.\n- Die statischen Beispiel-Zeichnungen (`fillRect`, `fillCircle` mit fixen Zahlen) solltest du durch Methoden wie `player.draw(gui)`/`ball.draw(gui)` ersetzen, damit alles aus dem Spielzustand kommt.\n\n\n# Exercise: stepstats\n\n### Correctness\n- In `StepTracker` fehlt die Klassen-/Methodensignatur wie in der Vorlage/Beispiellösung (`public class StepTracker { public static void main(String[] args) { ... } }`). Mit `void main()` auf Top-Level kompiliert das in normalem Java nicht.\n- In `StepTracker` fehlen die nötigen Imports (mindestens `java.util.Scanner`), sonst lässt sich `Scanner` nicht verwenden.\n- Wenn `steps.length == 0`, bleiben `minSteps` und `maxSteps` auf `Integer.MAX_VALUE`/`Integer.MIN_VALUE`, wodurch die ausgegebenen Minimal-/Maximalwerte in diesem Fall nicht sinnvoll sind.\n\n### Suggestion\n- Orientiere dich bei `StepTracker` an der erwarteten Java-Programmstruktur: eine öffentliche Klasse und eine `static`-`main`-Methode mit `String[] args`.\n- Prüfe, welche Klassen du verwendest (`Scanner`, evtl. `IO`) und stelle sicher, dass du die passenden Imports bzw. das gleiche IO-Setup wie in der Projektvorlage nutzt.\n- Überlege dir, was dein Programm ausgeben soll, wenn der User „0 days“ eingibt: Entweder diesen Fall verhindern oder die Statistikfelder in diesem Fall gezielt setzen/handhaben.\n\n### Code Style\n- Die Felder sind alle `public`; üblich wäre, sie zu kapseln (z.B. `private` + Getter) oder zumindest zu begründen, warum sie öffentlich sein sollen.\n- Innerhalb des Konstruktors mischst du `this.avgSteps` und direkte Feldzugriffe; einheitlicher Stil (entweder konsequent mit/ohne `this`, wo nötig) verbessert die Lesbarkeit.\n- Einrückungen im `for`-Block sind teils ungleichmäßig (z.B. `successDays++`, `totalSteps += step;`), was das Lesen erschwert.\n",
"status" : "SUCCESS"
}
}