{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- `listTasks(...)`: Wenn keine Tasks vorhanden sind (oder bei `list to do` alle Tasks erledigt sind), gibst du nicht `\"(No tasks)\"` aus, wie in der Aufgabenstellung verlangt.\n- `listTasks(false)`: Du filterst „nicht erledigt“ über `toString()`/String-Suche nach `\"true\"` statt über das `done`-Feld; dadurch kann die Ausgabe falsch werden (z. B. wenn die Beschreibung das Wort „true“ enthält oder das `toString()`-Format geändert wird).\n- `Task.toString()`: Die Ausgabe entspricht nicht dem geforderten Format (in den Beispielen z. B. mit `[id]`, optionalem ✓ und ohne `Task{...}`-Wrapper). Dadurch sieht die Konsolenausgabe nicht wie verlangt aus.\n- `markTaskDone(int id)`: Du iterierst zwar über `i`, verwendest aber immer `tasks.get(id)`; das ist logisch inkonsistent und kann auch fehlschlagen (z. B. bei ungültiger ID).\n- `markTaskDone(int id)`: Wenn `id` außerhalb des gültigen Bereichs liegt (z. B. `id >= tasks.size()`), bekommst du eine Exception statt der geforderten Meldung `\"Task with ID XX not found\"`.\n\n### Suggestion\n- Baue in `listTasks(...)` eine Art „wurde etwas ausgegeben?“-Merker ein und gib am Ende `\"(No tasks)\"` aus, falls nichts gedruckt wurde (gilt auch für `list to do`).\n- Für `list to do`: Prüfe direkt das boolean-Feld (`task.done`) anstatt Text in einem String zu suchen.\n- Passe `toString()` so an, dass es genau die gewünschte Konsolenzeile liefert (ID und Done-Markierung), damit `IO.println(task);` automatisch korrekt formatiert ist.\n- In `markTaskDone`: Entferne die unnötige Schleife und arbeite direkt mit der ID (die ID soll ja genau dem Platz entsprechen). Prüfe dabei zuerst, ob die ID gültig ist, bevor du `get(id)` aufrufst.\n- Achte bei der „not found“-Meldung darauf, dass der Text exakt zur Aufgabenbeschreibung passt (inkl. „ID“/Format).\n\n### Code Style\n- `getDone(boolean done)` ist vom Namen her irreführend (es ist ein Setter, kein Getter). Besser wäre ein Name, der „set…“ ausdrückt oder eine Methode wie „markDone()“ ohne Parameter.\n- In `listTasks(false)` die Umwandlung `String t = String.valueOf(tasks.get(i));` und `contains(\"true\")` ist sehr fragil und schwer wartbar; nutze stattdessen die Felder des Objekts.\n- `markTaskDone` enthält eine Schleife, die keinen Zweck erfüllt (weil du `i` nicht verwendest) – das macht den Code unnötig kompliziert.\n- Du mischst `IO.println`/`IO.print` mit `System.out.println`; besser bei einem Ausgabeweg bleiben, damit das Verhalten einheitlich ist.\n- In `addTask`: Der `null`-Check in einer `ArrayList` bringt nur etwas, wenn du tatsächlich irgendwo `null`-Einträge einfügst; normalerweise wächst eine `ArrayList` und hat keine „freien Plätze“.\n\n\n# Exercise: energymeter\n\n### Correctness\n- In `fill(double energy)` prüfst du `energy < 0` erst **nachdem** du `level` bereits erhöht und ggf. gecappt hast; bei negativem Input ändert sich der Zustand also trotzdem kurz/teilweise, obwohl eine Exception fliegen sollte.\n- `percentFull()` liefert bei `capacity == 0` kein definiertes korrektes Ergebnis: `level*100/capacity` führt zu Division durch 0 (Infinity/NaN), statt ein sinnvolles Resultat zurückzugeben.\n- `percentFull()` verändert im `else`-Zweig den Zustand (`capacity = level/10`), obwohl die Methode nur einen Prozentwert berechnen sollte; außerdem hängt der Rückgabewert dadurch nicht mehr sauber von den ursprünglichen Meter-Werten ab.\n- Die Logik `if (capacity >= level)` in `percentFull()` ist nicht passend für die Prozentberechnung: relevant ist vor allem der Fall `capacity == 0` sowie generell `level/capacity`; ob `level` größer ist als `capacity` sollte nicht zu einer Änderung von `capacity` führen.\n\n### Suggestion\n- Überlege bei `fill`: Wann soll der Zustand verändert werden—vor oder nach der Validierung? Platziere die Negativprüfung so, dass bei ungültigem Input **gar keine** Änderung am `level` passiert.\n- Behandle in `percentFull()` den Sonderfall `capacity == 0` explizit, bevor du dividierst.\n- In `percentFull()` sollte die Methode nur **berechnen und zurückgeben**, nicht Attribute verändern. Prüfe, welche Attribute du dort schreibst und ob das wirklich zur Aufgabenbeschreibung passt.\n- Falls du Angst hast, dass `level > capacity` vorkommen kann: Frage dich, welche Methoden dafür verantwortlich sind, und ob du das nicht dort (z. B. beim Füllen) begrenzen willst, statt in `percentFull()` die Kapazität umzubiegen.\n\n### Code Style\n- Die Aufgaben-/Beispiellösung verwendet package-private (ohne `public`) für Attribute/Konstruktor/Methoden; falls die Unit-Tests das erwarten, kann `public` zu Problemen führen. Prüfe die vorgegebenen Tests bzw. die geforderte Sichtbarkeit.\n- `percentFull()` enthält einen unnötigen `else`-Zweig mit Zustandsänderung und ein `return 100` am Ende, das die Logik unklar macht; versuche eine klarere, geradlinige Struktur mit frühzeitigem Return.\n- Kleine Konsistenz: Leerzeichen (`double capacity ;`) und Exception-Messages sind uneinheitlich; einheitliche Formatierung und Sprache erleichtern das Lesen.\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 Aufgabenstellung verlangt, dass man nach dem Konstruktor direkt über **die Attribute** wie `stats.successDays`, `stats.averageSteps`, `stats.minSteps`, `stats.maxSteps` zugreifen kann; bei dir heisst das Attribut für den Durchschnitt `averageSteps`, im Aufgabentext/Beispiel wird aber `averageSteps` verwendet (passt), jedoch wird im Beispiel `avgSteps` gezeigt – achte darauf, dass dein Code und der erwartete Client-Code wirklich dieselben Attributnamen verwenden, wie in der Aufgabenbeschreibung vorgegeben.\n- In `StepStatistics` berechnest du den Durchschnitt mit `averageSteps += (double) totalSteps / steps.length;` – das ist eine **Addition** auf einen (implizit) schon vorhandenen Wert, statt eine klare Zuweisung des Resultats. Das kann bei mehrfacher Verwendung/Erweiterung zu falschen Resultaten führen.\n\n### Suggestion\n- Vergleiche die verlangte Verwendung aus der Aufgabenbeschreibung exakt mit deinen Feldnamen und passe sie so an, dass ein Client wirklich genau diese Namen verwenden kann, ohne extra Variablen/Mapping zu brauchen.\n- Überlege beim Durchschnitt: soll der Wert jedes Mal **neu gesetzt** werden oder bewusst **aufaddiert** werden? Prüfe, was beim ersten und bei einem hypothetischen zweiten Durchlauf passieren würde.\n\n3. Code Style:\n- `totalSteps` ist package-private und eingerückt wie ein Blockfehler; mach die Einrückung konsistent und entscheide bewusst, welche Felder `public` sein sollen und welche nicht (aktuell ist es gemischt ohne klare Linie).\n- `totalSteps` muss kein Feld sein (es wird nur zur Berechnung im Konstruktor gebraucht); als lokaler Wert im Konstruktor wäre es übersichtlicher.\n- Die großen Kommentarblöcke mit den Fragen/Antworten gehören eher in eine Abgabe-Dokumentation oder ins README als in die Klasse selbst (und sie sind inhaltlich auch nicht wirklich als Code-Kommentar hilfreich für die Implementierung).\n",
"status" : "SUCCESS"
}
}