{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks(false)` werden erledigte Tasks trotzdem ausgegeben: Dein `else if (!task.state)` greift unabhängig vom Parameter `all`, dadurch landet bei „list to do“ auch alles (inkl. done) in der Ausgabe.\n- Wenn `tasks.length == 0`, druckst du zwar `(No tasks)`, läufst aber danach trotzdem weiter in die Schleife (aktuell harmlos, weil sie leer ist). Problematisch wird’s aber im Fall „es gibt Tasks, aber keiner passt zum Filter“: Dann wird bei dir **kein** `(No tasks)` ausgegeben, obwohl laut Aufgabenstellung genau dann diese Meldung kommen soll (z. B. „list to do“, aber alle sind done).\n- Die Fehlermeldung bei ungültiger ID soll exakt dem vorgegebenen Format entsprechen: `\"Task with ID XX not found\"` (mit `XX` als Platzhalter im Text). Du setzt stattdessen die konkrete Zahl ein und der Text weicht ab.\n\n### Suggestion\n- Überlege in `listTasks`, welche Kombinationen von `(all == true/false)` und `(task.state == true/false)` wirklich gedruckt werden sollen. Ein guter Ansatz ist: „Drucke, wenn `all` **oder** der Task noch nicht erledigt ist“ – und zwar als eine einzige Bedingung.\n- Für `(No tasks)` brauchst du nicht nur den Fall „Array ist leer“, sondern auch den Fall „es wurde aufgrund des Filters nichts gedruckt“. Baue dir dafür eine Variable, die merkt, ob mindestens ein Task tatsächlich ausgegeben wurde.\n- Schau dir die Aufgabenbeschreibung zur Fehlermeldung genau an und passe den ausgegebenen String so an, dass er wirklich exakt übereinstimmt (inkl. der `XX` im Text, so wie gefordert).\n\n### Code Style\n- `public Task[] tasks = new Task[0];` ist funktional, aber ungewöhnlich; meist initialisiert man direkt mit einer sinnvollen Kapazität (oder nutzt eine Liste). Das macht den Code einfacher und vermeidet dauerndes Kopieren.\n- In `Task` ist `state` semantisch etwas unklar; ein Name wie `done` wäre näher an der Aufgabenbeschreibung und leichter zu lesen.\n- Die Felder (`id`, `description`, `state`) sind alle `public`. Üblicher ist, sie zu kapseln (private) und gezielt über Methoden/Konstruktor zu setzen, damit der Zustand nicht überall beliebig verändert werden kann.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Sichtbarkeit von Konstruktor und Methoden ist bei dir `public`, während in der Aufgaben-/Test-Umgebung sehr wahrscheinlich package-private (ohne `public`) erwartet wird; das kann dazu führen, dass die Unit-Tests nicht gegen die geforderten Signaturen matchen.\n\n### Suggestion\n- Schau dir genau an, wie die Tests die Klasse instanziieren und Methoden/Attribute aufrufen (inkl. Modifier). Passe die Modifier so an, dass die Signaturen exakt zu dem passen, was die Tests erwarten (insbesondere: ob `public` erlaubt/erwartet ist oder nicht).\n\n### Code Style\n- `capacity` und `level` sind als `public` Felder exponiert; üblich wäre, den Zustand zu kapseln (z. B. nicht-öffentlich) und über Methoden zu steuern, damit kein externer Code ungültige Werte setzen kann.\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- In der Aufgabenstellung wird die Nutzung mit `double avgSteps = stats.averageSteps;` gezeigt, aber deine Klasse stellt `averageSteps` bereit; wenn der vorgegebene Client-Code/Tests exakt diese Feldnamen erwarten, kann das zu einem Mismatch führen.\n- In b) steht explizit, dass die Berechnungen im Konstruktor durchgeführt werden; bei dir passiert die eigentliche Berechnung in einer separaten Methode (`computeStatistics`), die der Konstruktor nur aufruft (funktional ok, aber je nach strenger Auslegung/Tests möglicherweise nicht wie verlangt).\n\n### Suggestion\n- Vergleiche deine Attributnamen genau mit denen, die im Aufgabentext für den Zugriff gezeigt werden (insbesondere `avgSteps` vs. `averageSteps`) und überlege, ob du dich daran anpassen musst.\n- Wenn „Berechnungen im Konstruktor“ wörtlich geprüft wird: Überlege, ob du die Logik so umorganisieren kannst, dass es klar im Konstruktor passiert (oder dass es zumindest nach außen nicht wie eine „zusätzliche Berechnungsmethode“ wirkt).\n\n### Code Style\n- Du hast öffentliche, veränderbare Felder (`public`); üblich wäre eher Kapselung (z. B. `private` + Getter) oder zumindest `final`, wenn sie nach dem Konstruktor nicht mehr geändert werden sollen.\n- In `computeStatistics` überschattest du die Felder mit lokalen Variablen gleichen Namens (`int successDays`, `int minSteps`, …). Das ist fehleranfällig und erschwert das Lesen; entweder andere lokale Namen wählen oder direkt mit `this.` arbeiten.\n- Die Initialwerte der Felder (`minSteps = 0`, `maxSteps = 0`) sind irreführend, weil sie sowieso überschrieben werden; entweder passend initialisieren oder gar nicht initialisieren und erst im Konstruktor setzen.\n- `computeStatistics` ist Teil der öffentlichen API, obwohl es offenbar nur intern gebraucht wird; wenn du sie behältst, wäre `private` naheliegender.\n",
"status" : "SUCCESS"
}
}