{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Du verwendest eine `ArrayList<Task>` statt des geforderten Arrays für Task-Objekte; die Aufgabenstellung verlangt explizit ein Array und dass die ID dem Platz im Array entspricht.\n- In `addTask` nutzt du `tasks.addLast(newTask)`; bei einer `ArrayList` gibt es diese Methode nicht (das führt so zu einem Compile-Fehler).\n- Die Methode `main` ist bei dir nicht als Java-Entry-Point umgesetzt (`public static void main(String[] args)` fehlt bzw. die Signatur passt nicht zum üblichen Startpunkt), sodass das Programm je nach vorgegebenem Gerüst nicht startbar ist.\n\n### Suggestion\n- Schau dir die TODOs/Kommentare im Gerüst an: Dort steht, dass zuerst der „erste freie Platz im Task-Array“ gesucht werden soll. Überlege, wie du ein festes `Task[]` anlegst und wie du freie Plätze erkennst (z. B. `null`).\n- Wenn du bei einer Listen-Implementierung bleibst, prüfe die korrekte API: Für eine `ArrayList` ist das Hinzufügen am Ende typischerweise über eine andere Methode gelöst als `addLast`.\n- Vergleiche deine `main`-Signatur mit dem, was im bereitgestellten Projekt als Startmethode erwartet wird (meist `public static void main(String[] args)` oder ein `run()`-Pattern, das von dort aufgerufen wird).\n\n### Code Style\n- Felder in `Task` sind alle `public`; üblicher ist, sie zu kapseln (private) und über Methoden zu ändern/abzufragen, damit z. B. `done` nicht von überall beliebig gesetzt wird.\n- In `listTasks` ist die Logik für `(No tasks)` doppelt/verteilt (einmal über `isEmpty()`, einmal über `counter`); das lässt sich meist klarer strukturieren, indem du nur einmal entscheidest, ob überhaupt etwas ausgegeben wurde.\n- `toString()` sollte mit `@Override` annotiert werden, damit der Compiler dich warnt, falls die Signatur nicht exakt stimmt.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Der Konstruktor setzt `level` nicht explizit auf `0`; falls die Tests erwarten, dass der Startzustand definiert initialisiert wird, kann das zu einem Fehlschlag führen.\n- `percentFull()` berechnet bei `level == 0` und `capacity > 0` einen Ausdruck mit Division durch 0 (`capacity / level`) und liefert dann nicht das erwartete Ergebnis (typisch wäre hier 0%).\n- `percentFull()` verwendet eine unglückliche Umformung (`100 / (capacity / level)`), die in manchen Fällen durch Rundung/Division-Order zu falschen Resultaten führen kann (insbesondere bei sehr kleinen/großen Werten).\n\n### Suggestion\n- Überlege im Konstruktor: Welcher Anfangsfüllstand ist in der Aufgabenbeschreibung/Tests gemeint, und solltest du ihn explizit setzen statt dich auf Default-Werte zu verlassen?\n- In `percentFull()`: Prüfe getrennt die Spezialfälle `capacity == 0` und `level == 0` (bei nicht-null capacity). Was sollte ein leerer Meter in Prozent zurückgeben?\n- Schreib die Prozentformel so, dass du keine Division durch `level` brauchst. Starte von „Anteil = level / capacity“ und skaliere dann auf Prozent.\n\n### Code Style\n- Die Attribute sind `public`; besser kapseln (z. B. `private`) und Zugriff über Methoden, damit der Zustand nicht von außen beliebig verändert werden kann.\n- Du hast viele `else`-Zweige nach `throw`; nach einem `throw` kannst du oft direkt weiterschreiben und die Einrückung reduzieren (macht es lesbarer).\n- Einheitliche Vergleichsoperatoren: In `fill` nutzt du `>=`, in `consume` `<=`. Das ist ok, aber achte darauf, ob du wirklich Gleichheit als „clampen“ behandeln willst (konsistent und bewusst).\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\n1. Correctness \n- In der Aufgabenbeschreibung soll die Klasse so verwendet werden können, dass das Attribut `averageSteps` über `stats.averageSteps` verfügbar ist; im gegebenen Beispiel steht aber `averageSteps` **nicht**, sondern `avgSteps`. Wenn die Tests/der Client exakt dieses Attribut (`avgSteps`) erwartet, würde dein Code daran scheitern (Namensabweichung). \n- `StepTracker` ist nicht an das vorgegebene Paket-/Klassen-Schema angepasst: Es fehlt die `package ch.fhnw.prog1.exercise.stepstats;` Deklaration und die übliche `public static void main(String[] args)` Signatur. Wenn die Vorlage/Abgabe genau diese Struktur erwartet, kompiliert es so nicht. \n- In `StepTracker` verwendest du `IO` und `Scanner`, importierst `Scanner` aber nicht und `IO` ist in der gezeigten Datei nicht definiert/importiert. Falls die Vorlage nicht automatisch `IO` bereitstellt bzw. `Scanner` nicht importiert ist, gibt das Compile-Fehler.\n\n2. Suggestion \n- Schau in der Aufgabenstellung bzw. in der restlichen Vorlage nach, **wie das Attribut für den Durchschnitt heissen soll** (z. B. `avgSteps` vs. `averageSteps`) und benenne es so, dass der Client-Code/Tests ohne Anpassung darauf zugreifen können. \n- Vergleiche deine `StepTracker`-Datei mit der vorgegebenen Struktur in der Vorlage: Achte darauf, dass **Package-Deklaration und `main`-Methode** genauso vorhanden sind, wie es das Projekt erwartet. \n- Prüfe, ob in eurer Vorlage `IO` tatsächlich existiert. Falls ja, stelle sicher, dass die Datei im richtigen Package liegt; falls nein, verwende die gleiche Ein-/Ausgabe-Art wie im Rest der Vorlage und ergänze fehlende Imports.\n\n3. Code Style \n- Du nutzt teils `this.` und teils nicht (`Math.min(minSteps, step)` vs. `this.minSteps = ...`). Entscheide dich konsequent für eine Variante, das macht den Code leichter zu lesen. \n- Die Felder sind alle `public`. Für saubere OOP wäre normalerweise `private` + Getter sinnvoll, aber hier verlangt die Aufgabe explizit Zugriff über Attribute – falls eure Kurskonvention trotzdem Kapselung möchte, kläre das mit der Aufgabenstellung/Tests.\n",
"status" : "SUCCESS"
}
}