{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Du verwendest eine `ArrayList<Task>` statt dem geforderten Array für Task-Objekte.\n- `listTasks(boolean all)` berücksichtigt den Parameter `all` nicht und filtert damit weder “all” noch “to do” korrekt.\n- `listTasks` gibt nicht einzelne Tasks aus, sondern druckt in jeder Schleifeniteration die String-Repräsentation der gesamten Liste; außerdem fehlt die geforderte Ausgabe von `\"(No tasks)\"`, wenn nichts ausgegeben wird.\n- `Task.toString()` entspricht nicht der geforderten Ausgabeform (es wird ein Debug-String mit Klassenname/Feldern ausgegeben, nicht die gewünschte Task-Darstellung wie in der Beispielausgabe mit ID/Done-Status/Description).\n- `addTask` sucht “freie Plätze” über `null`-Einträge, aber bei einer normalen `ArrayList` entstehen solche `null`-Lücken durch `add` nicht automatisch; damit erfüllt es die Idee “erster freier Platz im Task-Array = ID” nicht wie verlangt.\n- `markTaskDone(int id)` hat eine Schleife, die inhaltlich nichts korrekt iteriert (du nutzt `i` nicht) und setzt den Status immer basierend auf `tasks.get(id)`; bei ungültiger ID führt das zu einem Fehler statt zur geforderten Meldung.\n- Die Fehlermeldung in `markTaskDone` entspricht nicht der Vorgabe `\"Task with ID XX not found\"` (Format/Text weicht ab).\n- In `Task` heißt die Methode `getDone(boolean)` zwar so, aber sie setzt den Status; dadurch ist sie funktional missverständlich und du nutzt sie als “setter” (was zwar setzten kann, aber nicht zur Aufgabenbeschreibung “mark done” passt, die einfach den Task als erledigt markiert).\n\n### Suggestion\n- Schau in den TODOs der Aufgabe: Dort ist explizit ein Array vorgesehen. Überlege, wie du ein `Task[]` anlegst und wie du die “benutzte Länge” (z. B. ein Zähler) verwaltest, damit IDs stabil dem Index entsprechen.\n- Für `listTasks(all)`: Überlege dir eine Variable, die merkt, ob überhaupt etwas ausgegeben wurde. Gib nur Tasks aus, die existieren, und je nach `all` entweder alle oder nur die mit `done == false`.\n- Beim Ausgeben: Drucke wirklich das einzelne Task-Objekt (`IO.println(task)`), nicht die ganze Sammlung. Achte darauf, dass du das richtige Element (`tasks[i]`) druckst.\n- Für `\"(No tasks)\"`: Das soll erscheinen, wenn nach dem Filtern nichts gedruckt wurde (nicht nur wenn die Sammlung leer ist).\n- Für `toString()`: Richte dich an der Beispielausgabe (inkl. ID und Häkchen/Einrückung je nach done). Bau die String-Repräsentation so, dass `println(task)` genau diese Zeile ergibt.\n- Für `markTaskDone(id)`: Prüfe zuerst, ob `id` überhaupt in deinem Speicherbereich liegt und ob an der Stelle ein Task existiert. Nur dann den Done-Status setzen, sonst genau die geforderte Meldung ausgeben.\n- Wenn du eine Methode zum “Done setzen” in `Task` behalten willst, benenne/gestalte sie so, dass klar ist, dass sie setzt (und nicht “get” macht). Alternativ kannst du den Status direkt setzen, wenn das in eurem Kursstil erlaubt ist.\n\n### Code Style\n- In `markTaskDone` ist die `for`-Schleife unnötig, weil du immer nur `tasks.get(id)` verwendest; das macht den Code schwer verständlich.\n- `getDone(boolean done)` ist vom Namen her irreführend (Getter vs. Setter) und erschwert das Lesen.\n- In `listTasks` verwendest du `System.out.println` statt `IO.println` (im Gerüst ist `IO.println(task)` gefordert); bleib konsistent mit der vorgesehenen IO-Klasse.\n- Imports/Umgebung: In deinem ToDoApp-Ausschnitt fehlen sichtbare Imports für `ArrayList`/`Scanner`; achte darauf, dass die Datei vollständig kompilierbar ist.\n\n\n# Exercise: energymeter\n\n### Correctness\n- In `fill(double energy)` prüfst du `energy < 0` erst **nachdem** du `level` bereits verändert hast; bei negativen Werten wird der Zustand damit kurzzeitig falsch (und bleibt bei einer Exception ggf. in einem unerwarteten Zustand).\n- `percentFull()` ist fachlich falsch: Wenn `capacity == 0` bekommst du mit `level*100/capacity` eine Division durch 0; gefordert ist hier ein sinnvoller Rückgabewert.\n- `percentFull()` verändert außerdem `capacity` im `else`-Zweig (`capacity = level/10;`); die Methode soll nur einen Prozentwert liefern, nicht die Kapazität umschreiben.\n- Die Logik `if(capacity >= level)` ist nicht die richtige Bedingung, um zu entscheiden, ob du Prozent berechnen darfst; entscheidend ist, ob `capacity` 0 ist.\n- Konstruktor: Du setzt `this.capacity = capacity` bevor du die Negativprüfung machst; bei negativer Kapazität hat das Objekt kurzzeitig einen ungültigen Zustand (auch wenn danach eine Exception kommt).\n\n### Suggestion\n- Überlege bei `fill`: Welche Eingaben sind ungültig, und wann sollte die Exception kommen, damit sich `level` gar nicht erst ändert?\n- Für `percentFull`: Denke an den Sonderfall `capacity == 0` (was wäre dann ein plausibler “voll”-Wert?) und berechne sonst ganz normal den prozentualen Füllstand.\n- Lass `percentFull()` rein berechnend: Kein Feld sollte dort verändert werden. Falls du Fälle wie `level > capacity` abfangen willst, gehört das eher in `fill`/`consume` (oder in eine gemeinsame Korrekturlogik), nicht in die Prozentmethode.\n- Im Konstruktor: Prüfe erst den Parameter und setze danach die Felder, damit kein ungültiger Zwischenzustand entsteht.\n\n### Code Style\n- Sichtbarkeit: In der Vorlage/Beispiellösung sind Konstruktor und Methoden package-private (ohne `public`). Wenn die Unit-Tests im gleichen Package sind, kann `public` unnötig sein und vom erwarteten Interface abweichen.\n- Einheitliche Klammer-/Einrück-Formatierung würde die Lesbarkeit verbessern (z.B. Klammern immer direkt nach `if`-Bedingungen und konsistente Einrückung).\n- In `consume` ist `factor` als Variable nicht zwingend nötig; weniger Zwischenschritte machen den Code oft klarer, wenn der Ausdruck simpel ist.\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 Aufgabenbeschreibung sollen die Resultate über die Attribute `successDays`, `averageSteps`, `minSteps`, `maxSteps` zugreifbar sein; in deinem `StepStatistics`-Code heisst das Attribut für den Durchschnitt `averageSteps`, aber im Aufgabentext steht `averageSteps` (ok) – allerdings im Beispiel wird `avgSteps` verwendet. Wichtig ist hier: **StepTracker und StepStatistics müssen konsistent dieselben Namen verwenden**; prüfe, ob die Vorlage/Tests evtl. genau die Namen aus der Aufgabe erwarten.\n- Du berechnest den Durchschnitt mit `averageSteps += (double) totalSteps / steps.length;` statt zuzuweisen. Wenn das Objekt (warum auch immer) mehrfach verwendet/der Konstruktorlogik angepasst wird, kann das zu falschen Werten führen; für die aktuelle Verwendung ist das unnötig und potenziell fehleranfällig.\n\n### Suggestion\n- Kontrolliere, welche Attributnamen wirklich gefordert sind (Aufgabentext vs. Tests/Vorlage). Wenn ein Test auf einen bestimmten Namen zugreift, muss dein Feld exakt so heissen.\n- Schau dir die Zeile zur Durchschnittsberechnung an und überlege, ob du dort wirklich “aufaddieren” willst oder ob du den berechneten Wert “setzen” möchtest.\n\n### Code Style\n- Die Einrückung/Formatierung in `StepStatistics` ist inkonsistent (z.B. `int totalSteps;` ist anders eingerückt, und eine schliessende Klammer steht allein/versetzt). Einheitlich formatieren verbessert Lesbarkeit deutlich.\n- `totalSteps` ist als Feld deklariert, wird aber nur im Konstruktor benötigt; als lokale Variable im Konstruktor wäre klarer und reduziert Objektzustand.\n- Die grossen Block-Kommentare mit den Fragen/Antworten gehören eher in eine separate Textdatei oder an die passende Stelle im Aufgabenblatt, nicht in die Klassen-Datei (sonst “verrauschen” sie den Code).\n- In `StepTracker` fehlen in deinem Attempt (im Vergleich zur Beispielstruktur) Package-/Import-Angaben für `Scanner` und ggf. die Klasse, die `IO` bereitstellt; falls das in der Vorlage nicht automatisch da ist, wird es so nicht kompilieren.\n",
"status" : "SUCCESS"
}
}