{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks(false)` werden erledigte Tasks trotzdem ausgegeben: Deine zweite Bedingung `else if (!task.state)` greift unabhängig vom Parameter `all`, d. h. beim Befehl „list to do“ erscheinen auch erledigte Tasks nicht korrekt gefiltert.\n- In `listTasks(...)` wird `(No tasks)` nur dann ausgegeben, wenn `tasks.length == 0`. Wenn es Tasks gibt, aber wegen des Filters keine angezeigt werden (z. B. „list to do“ und alle sind erledigt), fehlt die geforderte `(No tasks)`-Meldung.\n- In `markTaskDone(int id)` gibst du bei ungültiger ID zwar die Meldung aus, aber der Text entspricht nicht der Aufgabenbeschreibung („Task with ID XX not found“). Falls im Test exakt auf den Text geprüft wird, kann das als falsch gewertet werden.\n\n### Suggestion\n- Schau dir die Logik in `listTasks(boolean all)` an: Überlege dir eine einzige Bedingung, wann ein Task ausgegeben werden soll, und verwende dabei `all` und den Done/State-Status gemeinsam (statt zwei getrennte Zweige, von denen einer `all` ignoriert).\n- Für `(No tasks)`: Zähle/merke dir, ob in der Schleife mindestens ein Task tatsächlich gedruckt wurde. Wenn nicht, gib am Ende `(No tasks)` aus – unabhängig davon, ob das Array leer ist oder nur „nichts passt“.\n- Bei der Fehlermeldung in `markTaskDone`: Vergleiche den exakten Wortlaut aus der Aufgabenstellung und übernimm ihn genau so (inkl. Platzhalter-Format), falls eure Tests darauf achten.\n\n### Code Style\n- Benennung: `state` ist inhaltlich „done/erledigt“ – ein sprechender Name wie `done` macht die Bedingungen in `listTasks` und `markTaskDone` deutlich lesbarer.\n- Felder in `Task` sind `public`; üblich wäre, sie zu kapseln (private) und über Konstruktor/Methoden zu arbeiten. Das ist nicht zwingend für die Aufgabe, verbessert aber Wartbarkeit.\n- Das manuelle Vergrößern des Arrays in `addTask` funktioniert, ist aber recht umständlich; in Java wird dafür typischerweise eine `ArrayList<Task>` verwendet (falls im Kurs schon erlaubt).\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Attribute und Methoden sind bei dir `public`; laut Vorgabe/Beispiel sind sie paket-sichtbar (ohne `public`). Das kann in den Unit-Tests zu Sichtbarkeits-/Signatur-Mismatches führen.\n\n### Suggestion\n- Schau dir genau an, wie die Tests/der Beispielcode die Sichtbarkeit erwarten: Entferne testweise die `public`-Modifier bei Attributen, Konstruktor und Methoden, sodass sie nur im Package sichtbar sind.\n\n### Code Style\n- Felder direkt `public` zu machen ist meist ungünstig (Kapselung); selbst wenn es für die Aufgabe nicht nötig ist, wäre es besser, den Zugriff über Methoden zu steuern.\n\n\n# Exercise: pong\n\n### Correctness\n- Beim Abprallen an der oberen/unteren Wand berücksichtigst du den Ball-Radius nicht: Du prüfst `ball.pY <= 0 || ball.pY >= HEIGHT`, zeichnest aber einen Kreis mit Radius 5. Dadurch “steckt” der Ball visuell schon halb in der Wand, bevor er umkehrt (bzw. kann kurz ausserhalb sein).\n- Die Kollision Ball–Schläger berücksichtigt die Ball-Grösse und die Schlägerbreite nicht sauber: links prüfst du z.B. `ball.pX - 10 <= player1.pX`, rechts nur `ball.pX >= player2.pX`. Das kann zu sehr frühen/späten oder mehrfachen Treffern führen (Ball prallt mehrfach in aufeinanderfolgenden Frames, weil er noch “im” Schläger bleibt).\n- Die Spawn-Logik “alle 1–2 Sekunden” ist nur beim ersten Intervall zufällig: `spawnInterval` wird zwar zufällig gesetzt, aber nach dem Spawnen nicht neu randomisiert. Danach ist das Intervall konstant.\n\n### Suggestion\n- Überlege dir bei Wandkollisionen immer mit dem Kreis-Bounding (Mitte ± Radius) zu arbeiten und setze die Position beim Umkehren ggf. auf den Rand zurück, damit der Ball nicht in der Wand verbleibt.\n- Für Paddle-Kollisionen hilft es, mit klaren Rechteck-/Kreis-Grenzen zu testen (oder zumindest konsequent Ballradius + Paddlebreite zu berücksichtigen) und nach einem Treffer den Ball minimal aus dem Schläger herauszuschieben, damit er nicht sofort erneut kollidiert.\n- Wenn wirklich “immer nach einer bis zwei Sekunden” ein neuer Ball kommen soll, dann würfle das Intervall nach jedem Spawn erneut (nicht nur einmal zu Beginn).\n\n### Code Style\n- In `Ball` sind Felder wie `pX/pY/vX/vY` und auch `random` public bzw. als Instanzfeld ohne Notwendigkeit; kapsle Spielzustand eher über Methoden (z.B. `move()`, `draw()`), dann bleibt `PongGame` übersichtlicher.\n- Benennung ist inkonsistent (`pX`/`pY` vs. im Aufgabenblatt `(px,py)`; `posX`/`pX` gemischt). Einheitliche Namen erleichtern Debugging.\n- Magic Numbers (z.B. `10` für Paddlebreite, `5` für Ballradius, `15` max. Bälle, `10` Schrittweite) tauchen mehrfach auf; als `static final` Konstanten wären sie zentral anpassbar.\n- In `PongGame` fehlt ein `package`-Statement, während `Ball`/`Player` eins haben; achte darauf, dass alle Dateien in der gleichen Package-Struktur liegen, sonst gibt’s je nach Setup Compile-/Import-Probleme.\n\n\n# Exercise: stepstats\n\n### Correctness\n- Die geforderte Verwendung nennt das Attribut `averageSteps` als `avgSteps` (und damit stimmt deine API nicht mit der Aufgabenbeschreibung überein).\n\n### Suggestion\n- Schau dir die vorgegebene Beispiel-Verwendung genau an und benenne/Expose die Attribute so, dass man sie exakt wie dort gezeigt auslesen kann (insbesondere beim Durchschnittswert).\n\n### Code Style\n- `computeStatistics` wird nur im Konstruktor verwendet; überlege, ob du die Berechnung nicht direkt im Konstruktor lassen willst, damit die Klasse klar “berechnet beim Erzeugen” und danach nur noch Werte bereitstellt.\n- Du deklarierst in `computeStatistics` lokale Variablen mit denselben Namen wie die Felder (`successDays`, `minSteps`, `maxSteps`). Das ist zwar funktional ok, aber leicht verwirrend; konsistentere Benennung würde die Lesbarkeit verbessern.\n- In `StepTracker` fehlen im gezeigten Code wichtige Dinge wie `package`/`class`-Deklaration und Imports (z.B. `Scanner`). Falls das nicht nur gekürzt ist, wird es so nicht kompilieren.\n",
"status" : "SUCCESS"
}
}