{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Deine `toString()`-Ausgabe entspricht nicht dem geforderten Format aus dem Beispiel: dort steht bei erledigten Tasks ein `✓` und es gibt eine Einrückung, außerdem wird kein `[X]`/`[ ]` gezeigt.\n- In `Task.toString()` fehlt ein Leerzeichen zwischen Status-Box und ID-Klammern (du erzeugst z.B. `\"[ ][0] ...\"`, im Beispiel ist es eher `\" [0] ...\"` bzw. `\" ✓ [0] ...\"`).\n- Der Einstiegspunkt ist als `void main()` definiert; normalerweise erwartet das Grundgerüst eine `public static void main(String[] args)` (oder eine vom Template vorgegebene Signatur). So wie es jetzt ist, könnte das Programm je nach Test/Runner gar nicht starten.\n\n### Suggestion\n- Orientiere dich bei `toString()` exakt an der Beispielausgabe: überlege, welche Zeichen (inkl. Leerzeichen) am Anfang stehen sollen, abhängig davon ob der Task erledigt ist, und wie ID/Description formatiert werden.\n- Wenn du dir unsicher bist, gib testweise genau einen Task im done/undone-Zustand aus und vergleiche die Ausgabe Zeichen für Zeichen mit dem Beispiel.\n- Prüfe im bereitgestellten Grundgerüst, welche `main`-Signatur dort erwartet wird (häufig ist sie vorgegeben). Passe deine Klasse daran an, damit die App überhaupt ausgeführt wird.\n\n### Code Style\n- `import ch.fhnw.prog1.exercise.todo.Task;` ist in `ToDoApp` unnötig, weil `Task` im selben Package liegt.\n- `tasks` ist `public`; besser wäre kapseln (z.B. `private`) und nur über Methoden darauf zugreifen.\n- In `listTasks` iterierst du immer über `tasks.length` (100). Funktioniert, ist aber unnötig viel Durchlauf; üblicher ist es, nur bis zur letzten belegten Position zu laufen (z.B. mit einem Zähler), dann bleibt es auch übersichtlicher.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Deine Sichtbarkeiten passen vermutlich nicht zu den Unit-Tests: In der Aufgabenbeschreibung sind Konstruktor und Methoden ohne `public` angegeben (package-private). Wenn die Tests im selben Package liegen und exakt diese Signaturen erwarten, führen `public EnergyMeter(...)`, `public void fill(...)`, `public void consume(...)`, `public double percentFull()` zu einem Mismatch.\n\n### Suggestion\n- Schau dir an, wie die Tests die Klasse instanziieren/aufrufen (oder was in der Vorlage/Beispielsignatur steht): Wenn dort `new EnergyMeter(...)` ohne `public`-Kontext bzw. package-private erwartet wird, entferne das `public` bei Konstruktor und Methoden, sodass die Signaturen exakt passen.\n\n### Code Style\n- Die Fehlermeldung im `IllegalArgumentException(\"Der Wert muss >= 0 sein\")` ist inkonsistent zu den anderen Würfen ohne Message; einheitlich halten (entweder überall mit oder überall ohne Message).\n- Du hast an mehreren Stellen `if/else`-Blöcke, die man kompakter ausdrücken könnte (z.B. erst rechnen, dann clampen), aber das ist optional – wichtiger ist Konsistenz und Lesbarkeit.\n\n\n# Exercise: pong\n\n### Correctness\n- Du hast die geforderten Klassen `Player` und `Ball` nicht erstellt (Teil a).\n- In `PongGame` werden keine zwei `Player`-Objekte und kein `Ball`-Objekt erzeugt und gespeichert (Teil a).\n- Der Ball startet nicht in der Mitte mit zufälliger Anfangsgeschwindigkeit (Teil a).\n- In der Spielschleife werden weder Spieler noch Ball bewegt (Teil c).\n- Kollisionen mit oberen/unteren Wänden für Ball und Begrenzung der Player im Spielfeld fehlen (Teil d).\n- Kollisionen Ball–Balken, Punktevergabe bei Seitenwand und Ball-Reset fehlen (Teil e).\n- Punktestand wird nicht gezeichnet (Teil e).\n- Mehrere Bälle (Array, periodisches Hinzufügen, Entfernen beim Verlassen, effiziente Verwaltung/Invariante) fehlen komplett (Teil f).\n\n### Suggestion\n- Leg zuerst kleine Datenklassen an: `Player` mit Position/Balkenlänge/Punkten und `Ball` mit Position und Geschwindigkeit; überleg dir, welche Werte du pro Frame brauchst, um zu zeichnen und zu bewegen.\n- Erzeuge in `main` zwei Player links/rechts (sinnvolle x-Positionen nahe Rand, y in der Mitte) und einen Ball in der Feldmitte; gib dem Ball eine zufällige Richtung und eine sinnvolle Geschwindigkeit (nicht 0).\n- Nutze die `isKeyPressed(...)`-Abfragen wirklich, um `py` der Player pro Frame zu verändern (auch “down”-Tasten ergänzen, sonst kann man nur hoch).\n- Für Wandkollisionen: prüfe beim Ball, ob er oben/unten “über den Rand” ist, dann korrigiere die Position zurück in den erlaubten Bereich und kehre die y-Geschwindigkeit um; für Player clampst du `py` so, dass der Balken im Feld bleibt.\n- Für Ball–Balken-Kollisionen hilft es, mit Rechtecken/Bounding-Boxen zu arbeiten (Ball als Quadrat um den Kreis) und Überschneidung zu testen; beim Treffer kehrst du die x-Geschwindigkeit um und schiebst den Ball aus dem Balken heraus, damit er nicht “klebt”.\n- Für Punkte: Wenn der Ball links oder rechts rausgeht, erhöhe den Punktestand des anderen Spielers und setze den Ball wieder in die Mitte (mit neuer zufälliger Geschwindigkeit).\n- Für Teil f: Ersetze den einzelnen Ball durch ein `Ball[]` plus eine Variable für “wie viele sind aktiv”; halte die Invariante, dass die aktiven Bälle in den ersten `n` Feldern stehen, dann kannst du Entfernen effizient machen (z.B. durch Ersetzen mit dem letzten aktiven Element).\n- Für das periodische Hinzufügen: zähle Frames herunter (bei 50 FPS entsprechen 50–100 Frames etwa 1–2 Sekunden) und füge bei 0 einen neuen Ball hinzu, wenn noch Platz im Array ist.\n\n### Code Style\n- Aktuell ist fast nur die Vorlage unverändert; entferne die TODO-Kommentare bzw. ersetze sie durch tatsächlichen Code, sobald du die Teile implementierst.\n- Die Variablen `p1Up` und `p2Up` werden gesetzt, aber nicht verwendet; entweder verwenden (Bewegungslogik) oder weglassen.\n- Für bessere Struktur: Zeichnen und Logik (Bewegung/Kollision) klar trennen (z.B. erst Updates, dann Rendering), und wiederkehrende Werte (Paddle-Größe, Geschwindigkeiten, Abstände) als Konstanten definieren.\n\n\n# Exercise: stepstats\n\n### Correctness\n- `StepTracker` ist nicht als ausführbare Java-Klasse mit `public static void main(String[] args)` umgesetzt (du hast nur `void main()`), dadurch startet das Programm in einer normalen Java-Umgebung nicht wie gefordert.\n- In `StepTracker` fehlen die nötigen Imports/Package-Deklaration für die verwendeten Klassen (`Scanner`, ggf. `IO` und das Package), sodass es je nach Vorlage nicht kompiliert.\n- Bei `steps.length == 0` bleiben `minSteps` und `maxSteps` auf `Integer.MAX_VALUE`/`Integer.MIN_VALUE`, was zu unsinnigen Ausgaben führt, falls „Anzahl Tage“ 0 eingegeben wird.\n\n### Suggestion\n- Schau dir an, wie in der Vorlage/Beispiel-Lösung die Einstiegsmethode und Klassenstruktur von `StepTracker` aufgebaut ist (Klasse + `public static void main(String[] args)`), und passe deinen Client-Code daran an.\n- Prüfe, welche `import`-Zeilen und welche `package`-Zeile am Dateianfang nötig sind, damit `Scanner` und die verwendete Ausgabe-Klasse (`IO` oder `System.out`) wirklich verfügbar sind.\n- Überlege dir, wie du den Fall „0 Tage“ behandeln willst: Entweder diese Eingabe verhindern/abfangen oder sinnvolle Default-Werte setzen, bevor du `minSteps/maxSteps` ausgibst.\n\n### Code Style\n- Deine Felder sind `public`; das funktioniert zwar, aber objektorientiert wäre es üblich, sie `private` zu halten und über Getter bereitzustellen (oder zumindest bewusst zu entscheiden, warum sie öffentlich sind).\n- Einheitlichkeit: Im Konstruktor nutzt du teils `avgSteps` und einmal `this.avgSteps`; entscheide dich für eine Variante und bleib konsistent.\n- Einrückung/Formatierung im `for`-Block ist etwas uneinheitlich (z. B. die Einrückung von `successDays++`, `totalSteps += step;` etc.); sauber formatieren hilft Lesbarkeit.\n",
"status" : "SUCCESS"
}
}