{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die Ausgabe eines Tasks entspricht nicht dem im Beispiel gezeigten Format: erwartet ist z. B. `\" ✓ [0] Waschen\"` bzw. `\" [1] Lernen\"`, bei dir kommt eher `\"[x] 0: Waschen\"` heraus (anderes Symbol, andere Klammerung, anderer Separator/Anordnung).\n- Deine `toString()`-Darstellung enthält `id` und `description` in einem anderen Layout als in der Aufgabenbeschreibung demonstriert; damit wird `IO.println(task);` nicht die erwartete Konsolen-Ausgabe erzeugen.\n\n### Suggestion\n- Orientiere dich beim String-Aufbau in `Task.toString()` exakt an der gezeigten Ausgabe (inkl. Leerzeichen/Einrückung, Position von `✓`, Klammern um die ID und ohne `:`). Baue dir am besten zwei Varianten (done vs. not done) und vergleiche sie Zeichen für Zeichen mit dem Beispiel.\n\n### Code Style\n- In `listTasks` iterierst du immer über das ganze 100er-Array; das funktioniert zwar, ist aber unnötig teuer. Üblicher ist es, nur bis zum “letzten benutzten” Eintrag zu laufen (z. B. mit einer separaten `used`-Variable) oder beim ersten `null` abzubrechen, wenn du garantiert vorne auffüllst.\n- Achte auf saubere Klassenstruktur/Klammerung: In deinem Snippet ist nicht klar ersichtlich, ob `Task` korrekt innerhalb/außerhalb von `ToDoApp` liegt und ob alle geschweiften Klammern wirklich passen (das führt schnell zu Compile-Fehlern).\n\n\n# Exercise: energymeter\n\n### Correctness\n- `percentFull()` liefert bei `level == 0` und `capacity > 0` den Wert `0` (weil du `level` zurückgibst), aber gefordert ist ein Prozentwert (also `0`, aber als Prozentberechnung konsistent) – dein Spezialfall ist hier logisch inkonsistent zur restlichen Methode.\n- `percentFull()` behandelt den Fall `capacity == 0` nur dann als `100`, wenn zusätzlich `level == 0` ist; falls `capacity == 0` und `level > 0`, teilst du durch `capacity` (über `capacity / level`) und bekommst eine Division durch 0 statt `100`.\n- Die Signatur von `consume` verwendet Parameternamen (`capacity`, `durance`), die nicht den geforderten Parametern entsprechen (Kapazität/Intensität und Dauer). Das kann bei den Unit-Tests zu Missverständnissen führen, weil du hier semantisch „capacity“ als Intensität nutzt.\n\n### Suggestion\n- Überlege dir für `percentFull()` eine einheitliche Formel, die immer einen Prozentwert liefert, und prüfe dabei zuerst den Sonderfall `capacity == 0`, unabhängig vom aktuellen `level`.\n- Prüfe, ob du in `percentFull()` überhaupt einen Sonderfall für `level == 0` brauchst, wenn deine allgemeine Prozentformel schon korrekt damit umgehen kann.\n- Benenne die Parameter von `consume` so, dass klar ist, dass es um Verbrauchs-„Intensität“ und „Dauer“ geht (und nicht um die Meter-`capacity`), damit du nicht aus Versehen Variable/Attribut verwechselst.\n\n### Code Style\n- Attribute (`level`, `capacity`) sind `public`; üblich wäre, sie zu kapseln (z. B. `private`) und nur über Methoden zugänglich zu machen, damit der Meterzustand nicht von außen beliebig verändert werden kann.\n- In `consume(double capacity, ...)` überschattet der Parametername `capacity` das gleichnamige Attribut; das ist fehleranfällig und schwer zu lesen.\n- Rechtschreibung/Benennung: `energie`, `durance` sind inkonsistent (Deutsch/Englisch gemischt, „duration“ falsch geschrieben). Einheitliche englische Namen wie in der Aufgabenbeschreibung verbessern Verständlichkeit.\n- Exception-Messages sind uneinheitlich („Energie must be positive“) und teils sprachlich gemischt; einheitliche Sprache/Begriffe helfen.\n\n\n# Exercise: pong\n\n### Correctness\n- In Teil f) soll ein neuer Ball „immer nach **einer bis zwei Sekunden**“ hinzukommen; bei dir ist das Intervall fix (`SPAWN_INTERVAL = 75`), also konstant statt zufällig im Bereich 1–2 s.\n- Bei der Kollision Ball–Wand oben/unten invertierst du nur `vy`, aber du korrigierst die Ballposition nicht zurück ins Spielfeld; dadurch kann der Ball (je nach Schrittweite) kurz „in der Wand stecken“ und ggf. in aufeinanderfolgenden Frames mehrfach flippen.\n\n### Suggestion\n- Für das Spawn-Intervall: Überleg dir eine Variable wie „framesUntilNextSpawn“, die du nach jedem Spawn neu auf einen zufälligen Wert setzt, der 50–100 Frames entspricht (bei 50 FPS).\n- Für die Wandkollision: Wenn du feststellst, dass `y - radius < 0` oder `y + radius > HEIGHT` ist, setze `y` zusätzlich auf den nächstgültigen Wert (z.B. genau `radius` bzw. `HEIGHT - radius`), bevor/ nachdem du `vy` umdrehst.\n\n### Code Style\n- Viele Felder in `Ball` und `Player` sind `public` (z.B. `x`, `y`, `vx`, `vy`, `score`); besser wäre Kapselung (private) und gezielte Methoden (z.B. fürs Punktezählen/Bewegen), damit `PongGame` nicht überall direkt in den Zustand schreibt.\n- `PongGame` hat keinen `package`-Header und `main()` ist nicht `public static void main(String[] args)`; je nach Projekt-Template/Autograder kann das ein Problem sein (auch wenn es in gewissen Umgebungen trotzdem läuft).\n- Die Zeichenposition für den Score nutzt einen „magischen Offset“ (`WIDTH / 2 - 20`); wenn du zentrieren willst, wäre GUI-Zentrierung bzw. eine klare Begründung/Konstante dafür lesbarer.\n\n\n# Exercise: stepstats\n\n### Correctness\n- In `StepTracker`, your `main` method signature (`void main()`) doesn’t match the usual Java entry point (`public static void main(String[] args)`), so it may not run as required in the given project setup.\n- `StepTracker` is missing the `package ch.fhnw.prog1.exercise.stepstats;` declaration that the exercise/template expects (and that your `StepStatistics` uses), which can break compilation depending on the folder/package structure.\n\n### Suggestion\n- Compare your `StepTracker` “outer structure” (package line, class declaration, and `main` signature) with how Java programs in this course/template are started; adjust yours so the runtime can actually find the entry point.\n- Ensure `StepTracker` is placed in the same package as in the template; if it’s in that folder, add the matching `package ...;` line at the top.\n\n### Code Style\n- Add the necessary imports explicitly in `StepTracker` (e.g., for `Scanner`) instead of relying on unspecified defaults; it makes the file self-contained and avoids compilation surprises.\n- Consider consistency with naming expected by the task statement: the example access shows `averageSteps` vs `avgSteps`; your choice is fine if the task doesn’t enforce exact names, but keep naming consistent across the project/spec.\n",
"status" : "SUCCESS"
}
}