{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks(boolean all)` berücksichtigst du den Parameter `all` nicht korrekt: Bei `all == false` werden aktuell auch erledigte Tasks ausgegeben (weil dein `else if (!tasks[i].state)` unabhängig von `all` greift und die erste Bedingung nur erledigte + all abdeckt).\n- `listTasks(...)` gibt nie `\"(No tasks)\"` aus, wenn keine Tasks vorhanden sind oder wenn bei `list to do` alle Tasks erledigt sind.\n- Die Aufgabenstellung verlangt, dass ein einzelner Task mit `IO.println(task);` ausgegeben wird und dafür `toString()` in `Task` implementiert wird. In deinem Code wird stattdessen manuell formatiert und `Task` hat keine `toString()`-Methode.\n- `markTaskDone(int id)` behandelt den Fall nicht, dass die ID ungültig ist (z. B. zu groß/klein oder `tasks[id]` existiert nicht). Laut Aufgabe soll dann `\"Task with ID XX not found\"` ausgegeben werden (mit der entsprechenden ID statt `XX`).\n- Die Ausgabe soll erledigte Tasks mit einem Häkchen anzeigen (wie im Beispiel `✓ [0] ...`). Deine Ausgabe unterscheidet nicht zwischen erledigt/nicht erledigt.\n\n### Suggestion\n- Überlege dir für `listTasks(all)`: Welche Tasks sollen bei `all == true` durchgelassen werden, und welche bei `all == false`? Formuliere die Bedingung so, dass „nur nicht erledigt“ wirklich nur dann ausgegeben wird.\n- Für `\"(No tasks)\"`: Du brauchst eine Art Merker/Zähler, ob überhaupt etwas ausgegeben wurde. Falls nicht, druckst du die Meldung am Ende einmal.\n- Implementiere `toString()` in `Task` so, dass die komplette gewünschte Darstellung dort entsteht (inkl. ID und evtl. Häkchen). Dann kann `listTasks` wirklich nur noch `IO.println(task);` machen.\n- Bevor du in `markTaskDone` auf `tasks[id]` zugreifst: prüfe, ob `id` überhaupt im gültigen Bereich liegt. Falls nicht, gib genau die geforderte Meldung aus und beende die Methode ohne Zugriff.\n- Für das Häkchen: Lass `Task` selbst wissen, ob er erledigt ist, und baue das in die String-Darstellung ein (damit `listTasks` nicht doppelt Logik/Formatierung enthalten muss).\n\n### Code Style\n- In `Task` sind alle Felder `public`; üblich wäre, die Felder zu kapseln (z. B. `private`) und gezielt über Methoden zu verändern/auszulesen.\n- Der Feldname `state` ist unklar; ein Name wie `done` beschreibt die Bedeutung direkter.\n- Der Konstruktor von `Task` verlangt `state` als Parameter, obwohl neue Tasks immer „nicht erledigt“ starten. Das erhöht unnötig die Fehlergefahr und macht Aufrufe länger als nötig.\n- `tasks` als `new Task[0]` und bei jedem `addTask` ein neues Array zu bauen funktioniert, ist aber unnötig umständlich/ineffizient im Vergleich zu einem ausreichend großen Array + „used“-Zähler (oder einer Liste).\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Sichtbarkeiten passen vermutlich nicht zu den vorgegebenen Unit-Tests: In der Aufgabenbeschreibung sind Konstruktor und Methoden ohne `public` angegeben (package-private). Mit `public` kann es sein, dass die Tests auf die “default”-Sichtbarkeit prüfen und dann fehlschlagen.\n\n### Suggestion\n- Schau dir die Signaturen in der Aufgabenbeschreibung bzw. im Testcode genau an: Ob `public` oder package-private erwartet wird, erkennt man daran, wie die Tests die Klasse aus demselben Package ansprechen und ob sie explizit auf Zugriffsebenen bestehen.\n\n### Code Style\n- `capacity` und `level` sind als `public` Felder offen zugreifbar; üblich wäre es, Zustände zu kapseln (z. B. `private`) und nur über Methoden zu verändern, damit Invarianten (0..capacity) nicht umgangen werden können.\n- In `fill` und `consume` könntest du Doppelberechnungen reduzieren (z. B. Ausdruck einmal berechnen und dann clampen), das macht den Code leichter lesbar.\n\n\n# Exercise: pong\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: stepstats\n\n### Correctness\n- Die geforderte Verwendung nennt das Attribut `averageSteps` als `avgSteps` (`double avgSteps = stats.averageSteps;` ist inkonsistent): In der Aufgabenbeschreibung wird einmal `averageSteps` erwähnt, aber das Beispiel und der restliche Kontext nutzen `avgSteps`. Mit deinem aktuellen Namen kann der Client-Code je nach Erwartung/Tests scheitern.\n\n### Suggestion\n- Schau dir die im Text geforderte Zugriffssyntax und die im Beispiel verwendeten Attributnamen an und entscheide dich konsequent für die Variante, die im Template/Tests erwartet wird (insbesondere beim Durchschnitts-Feld). Wenn du umbenennst, passe auch alle Zugriffe im `StepTracker` an.\n\n### Code Style\n- In `computeStatistics` überschattest du die Felder `successDays/minSteps/maxSteps` mit lokalen Variablen gleichen Namens. Das ist zwar funktional ok, aber unnötig verwirrend; nutze entweder direkt die Felder oder gib den lokalen Variablen andere Namen.\n- Du initialisierst `minSteps`/`maxSteps` als Felder mit `0`, obwohl du im Rechenlauf sowieso sinnvolle Startwerte nutzt. Das kann beim Lesen irritieren; initialisiere Felder entweder passend oder lass die Berechnung klar im Konstruktor passieren.\n- Wenn die Berechnung “im Konstruktor durchgeführt” werden soll, ist eine extra öffentliche Methode `computeStatistics(...)` nicht unbedingt nötig. Überlege, ob du sie wirklich öffentlich machen willst oder ob die Logik direkt im Konstruktor bleiben sollte.\n",
"status" : "SUCCESS"
}
}