{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Deine Ausgabe eines Tasks entspricht nicht dem geforderten Format: Im Beispiel steht u. a. ein Häkchen bei erledigten Tasks und die ID ist in eckigen Klammern (`✓ [0] ...` bzw. ` [0] ...`), bei dir kommt `id: description (done)`.\n- In `markTaskDone` ist die Fehlermeldung nicht exakt wie in der Aufgabenbeschreibung gefordert: Dort steht `\"Task with ID XX not found\"` (mit `XX` als Platzhalter), bei dir wird die tatsächliche ID eingesetzt.\n\n### Suggestion\n- Schau dir die geforderte Konsolen-Ausgabe in der Aufgabenstellung genau an und überlege, welche Informationen `toString()` liefern muss, damit `IO.println(task);` genau dieses Layout erzeugt (Einrückung, `[id]`, optionales Häkchen statt `\"(done)\"`).\n- Wenn du dich an die Aufgabenbeschreibung halten willst: Übernimm die Fehlermeldung in `markTaskDone` exakt so, wie sie im Kommentar vorgegeben ist (achte auf Wortlaut und Platzhalter).\n\n### Code Style\n- Benennung: `getID()` ist ungewöhnlich für Java-Getter; üblich wäre konsistent `getId()` (CamelCase).\n- In `listTasks` iterierst du immer über `tasks.length` (100). Das ist okay, aber mit einer separaten Variable für die Anzahl belegter Einträge (oder Abbruch beim ersten `null`, wenn du nie Lücken erzeugst) wird es klarer und effizienter.\n- In `addTask` passiert nichts, wenn das Array voll ist (stilles “Fail” ohne Meldung). Auch wenn nicht gefordert, wäre zumindest ein Kommentar oder eine Ausgabe hilfreich, damit das Verhalten nachvollziehbar bleibt.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Deine Methoden und Logik passen grundsätzlich, aber die Sichtbarkeit/Signaturen weichen vermutlich von den erwarteten Unit-Tests ab: Du hast Konstruktor und Methoden als `public` deklariert, während die Tests ggf. package-private Zugriff (ohne `public`) erwarten könnten.\n\n### Suggestion\n- Schau dir an, wie die Tests die Klasse instanziieren und die Methoden aufrufen (gleicher Package-Kontext?). Wenn die Tests ohne `public` arbeiten bzw. auf package-private Signaturen ausgelegt sind, entferne testkonform die `public`-Modifier bei Konstruktor und Methoden.\n\n### Code Style\n- Bei `consume` berechnest du `intensity * duration` mehrfach; das in eine lokale Variable auszulagern würde die Lesbarkeit erhöhen und doppelte Berechnung vermeiden.\n- Du hast konsequent Klammern gesetzt und klar strukturiert; optional könntest du die Grenzlogik in `fill/consume` jeweils erst rechnen und dann clampen, um weniger Verzweigungen zu haben (rein Lesbarkeit).\n\n\n# Exercise: pong\n\n### Correctness\n- In `PongGame` ist `main()` nicht als Java-Startpunkt deklariert (Signatur/`static`/`String[] args`), dadurch startet das Programm so nicht wie gefordert über eine normale `main`-Methode.\n- Der Ball startet nicht mit zufälliger Geschwindigkeit, sondern mit fest gesetzten Werten `(3.0, 2.0)`; in der Aufgabe soll die Startgeschwindigkeit zufällig sein.\n- Beim Punktgewinn soll der Ball „von Neuem“ in der Mitte starten (typisch inkl. neuer Startgeschwindigkeit); bei dir wird nur die Position zurückgesetzt, die Geschwindigkeit bleibt unverändert.\n- Erweiterung f) (mehrere Bälle, alle 1–2 Sekunden neuer Ball, Entfernen wenn Feld verlassen, Verwaltung über Array mit Maximalanzahl) ist nicht umgesetzt; aktuell gibt es genau einen Ball und keine Array-Verwaltung.\n\n### Suggestion\n- Schau dir an, welche exakte Methodensignatur Java als Programmeinstieg erwartet, und passe deine `main`-Methode daran an, damit die Klasse direkt ausführbar ist.\n- Für die zufällige Startgeschwindigkeit: überlege dir, wie du beim Erzeugen eines Balls `vx/vy` mit `Random` so wählst, dass Betrag und Richtung variieren (und nicht 0 werden).\n- Beim „Neu starten“ nach einem Punkt: überlege, welche Ball-Eigenschaften du neben `bx/by` ebenfalls zurücksetzen musst, damit sich ein Neustart wie ein neuer Aufschlag anfühlt.\n- Für mehrere Bälle: denk an eine Struktur wie `Ball[]` plus eine Variable, die zählt, wie viele Einträge gerade aktiv sind, und an einen Timer/Zähler in Frames (bei 50 FPS), um alle ~1–2 Sekunden einen neuen Ball hinzuzufügen und beim Verlassen effizient zu entfernen.\n\n### Code Style\n- Du berechnest `p1Up` und `p2Up`, verwendest die Variablen danach aber nicht; entweder nutzen oder entfernen.\n- Sehr viele Getter/Setter-Aufrufe in der Spielschleife machen den Code schwer lesbar; überlege, Ball/Player eher Methoden wie `move()`, `up()`, `down()` oder `reset()` zu geben, damit die Logik nicht überall verteilt ist.\n- Mehrere „Magic Numbers“ (z.B. `5` als Schrittweite, `50` als y-Position fürs Scoreboard, `-30` beim Spieler-x) würden als benannte Konstanten verständlicher.\n- Die Kollisionsabfragen sind direkt im Game-Loop „hineingeschrieben“; fürs Verständnis und Wartbarkeit wäre es sinnvoll, Kollision/Zeichnen/Bewegung in klar getrennte Abschnitte oder Hilfsmethoden auszulagern.\n\n\n# Exercise: stepstats\n\n### Correctness\n- In `StepTracker.java` fehlt die Paketdeklaration (`package ch.fhnw.prog1.exercise.stepstats;`), obwohl sie in der Vorlage/Beispiellösung erwartet wird und dein `StepStatistics` in genau diesem Package liegt.\n- `StepTracker` hat keine gültige Java-Entry-Point-Signatur: statt `void main()` wird (für ein normales Java-Programm) `public static void main(String[] args)` erwartet.\n- In `StepTracker.java` fehlen Imports/Abhängigkeiten für `Scanner` (und je nach Vorlage auch für `IO`), dadurch kompiliert es so nicht.\n\n### Suggestion\n- Schau dir an, in welchem Package `StepTracker` laut Aufgabenstruktur liegen soll, und stelle sicher, dass die Datei auch wirklich in diesem Package deklariert ist (nicht nur `StepStatistics`).\n- Verwende die übliche `main`-Methode, die von der JVM als Startpunkt erkannt wird; orientiere dich an der Signatur aus der Vorlage.\n- Ergänze die notwendigen Imports (z. B. für `Scanner`) bzw. prüfe, aus welcher Bibliothek `IO` kommt und ob das in deinem Projekt korrekt eingebunden/importiert ist.\n\n### Code Style\n- Deine Felder in `StepStatistics` sind `public` und damit von überall veränderbar; oft kapselt man so etwas (z. B. `private` + Getter oder zumindest `final`, wenn nach dem Konstruktor unveränderlich).\n",
"status" : "SUCCESS"
}
}