{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- In `listTasks(false)` werden erledigte Tasks trotzdem ausgegeben: Deine zweite Bedingung `else if (!task.state)` greift unabhängig von `all` und druckt alle nicht-erledigten Tasks, aber erledigte Tasks werden bei `all == false` nicht sauber ausgeschlossen/der Logikfluss ist nicht exakt „wenn all, dann alle; sonst nur nicht erledigte“.\n- In `listTasks(...)` wird `(No tasks)` nur geprüft, wenn `tasks.length == 0`. Wenn das Array zwar Elemente enthält, aber aufgrund von `all == false` keine davon ausgegeben wird (weil alle erledigt sind), fehlt die geforderte Ausgabe `(No tasks)`.\n- Die Aufgabenbeschreibung verlangt „zuerst den ersten freien Platz im Task-Array finden“ (Array mit freien Plätzen). Deine Lösung nutzt ein dynamisch wachsendes Array ohne freie Plätze; damit erfüllst du diese konkrete Vorgabe nicht (auch wenn es funktional ähnlich ist).\n\n### Suggestion\n- Für `listTasks(all)`: Überlege dir eine einzige klare Bedingung, wann ein Task gedruckt werden soll (z.B. „wenn all oder noch nicht done“). Zähle dabei mit (Flag/Counter), ob überhaupt etwas gedruckt wurde, und gib sonst am Ende `(No tasks)` aus.\n- Für das „erster freier Platz“-Requirement: Schau dir an, wie du ein Array mit fixer Größe verwenden kannst und dann den ersten Index findest, an dem noch kein `Task` gespeichert ist (z.B. `null`). Dieser Index soll dann gleichzeitig die ID sein.\n- Achte darauf, dass die „(No tasks)“-Meldung nicht nur vom Array-Längenfall abhängt, sondern davon, ob tatsächlich eine Zeile ausgegeben wurde.\n\n### Code Style\n- In `Task` sind die Felder `public`; üblich wäre, sie zu kapseln (private) und über Konstruktor/Methoden zu steuern (auch wenn es in Einsteigeraufgaben manchmal toleriert wird).\n- Der Name `state` ist weniger aussagekräftig als z.B. `done` (in deinem Code sieht man erst später, was `state` bedeutet).\n- In `listTasks` fehlt nach dem `(No tasks)`-Print ein `return`; so läuft die Methode weiter (funktional hier meist egal, aber unnötig/unklar).\n- Du kopierst bei jedem `addTask` das komplette Array; das ist für diese Aufgabe nicht nötig und macht den Code schwerer als er sein muss, wenn eigentlich ein fixes Array mit freien Plätzen gefordert ist.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Sichtbarkeit von Attributen, Konstruktor und Methoden ist bei dir `public`, während in der Aufgabenbeschreibung nur „Attribut/Methode“ steht und die Beispiel-API package-private ist; falls die Unit-Tests genau diese Signaturen/Sichtbarkeiten erwarten, könnten sie dadurch fehlschlagen.\n\n### Suggestion\n- Schau in die vorgegebenen Unit-Tests (oder die erwartete API im Aufgabenblatt): Wenn dort ohne `public` gearbeitet wird bzw. der Konstruktor/Methoden nicht öffentlich sein sollen, passe die Modifier so an, dass sie exakt zur erwarteten Sichtbarkeit passen.\n\n### Code Style\n- Felder (`capacity`, `level`) direkt `public` zu machen ist meist ungünstig (bricht Kapselung). Üblicher ist: Felder nicht öffentlich und Zugriff nur über Methoden.\n- In `consume` wäre es lesbarer, die beiden Parameterprüfungen getrennt zu halten (wie beim Rest), statt sie in einer Bedingung zu kombinieren.\n\n\n# Exercise: pong\n\n### Correctness\n- In Teil f) sollen Bälle entfernt werden, sobald sie das Spielfeld seitlich verlassen; bei dir werden sie stattdessen per `resetBall(...)` wieder in die Mitte gesetzt und bleiben aktiv.\n- Die Ball-Erzeugung in f) soll “immer nach einer bis zwei Sekunden” passieren; bei dir ist es fix auf 4000 ms (4 Sekunden) eingestellt und damit nicht im geforderten Bereich.\n- Beim Abprallen an der oberen/unteren Wand prüfst du `ball.pY <= 0 || ball.pY >= HEIGHT`, berücksichtigst aber den Ballradius nicht; dadurch ist der Ball teilweise schon aus dem Feld, bevor er abprallt.\n- Für die Wandkollision setzt du die Position nicht zurück in einen gültigen Bereich (nur `vY *= -1`), was bei größeren Geschwindigkeiten zu “Steckenbleiben”/Flackern am Rand führen kann, weil der Ball nach dem Flip immer noch außerhalb sein kann.\n- Bei der Schlägerkollision verwendest du für links `ball.pX - 10 <= player1.pX` und für rechts `ball.pX >= player2.pX`; das berücksichtigt weder die Schlägerbreite noch den Ballradius konsistent und kann dazu führen, dass Kollisionen zu früh/zu spät oder auch von “hinten” auslösen.\n- Die zufällige Ballgeschwindigkeit kann bei dir 0 werden (für `vX` und/oder `vY`), wodurch ein Ball stehen bleibt oder nur vertikal/horizontal läuft; das ist für “Ball bewegt sich” bzw. sinnvolle Startgeschwindigkeit meist nicht beabsichtigt.\n\n### Suggestion\n- Überlege bei f), was “entfernen” konkret heisst: Statt den Ball zu resetten, müsste die Anzahl aktiver Bälle sinken und der Ball aus deiner aktiven Datenstruktur verschwinden (z.B. `ballCount--` + Element aus dem “aktiven Bereich” entfernen/ersetzen).\n- Für “1–2 Sekunden” Spawnzeit: nutze einen zufälligen Intervall (z.B. beim Spawnen den nächsten Spawn-Zeitpunkt/Delay neu zufällig setzen) statt einen festen Wert.\n- Denk bei Kollisionen immer in “Bounding Box”/Radius: Verwende bei Wänden `pY - radius` und `pY + radius` (analog bei X), damit das sichtbare Objekt nicht durch die Wand ragt.\n- Wenn du die Geschwindigkeit invertierst, setz zusätzlich die Position so, dass der Ball wieder innerhalb des erlaubten Bereichs liegt (z.B. genau auf die Grenze), damit er nicht im nächsten Frame erneut kollidiert.\n- Für Schlägerkollisionen: Prüfe die Überlappung in X *und* Y mit Ballradius und Schlägerbreite (rechte/linke Kante des Schlägers), statt nur mit einem einzelnen X-Vergleich; damit verhinderst du auch Mehrfach-Kollisionen in aufeinanderfolgenden Frames.\n- Stell sicher, dass beim Randomisieren `vX` nicht 0 ist (und idealerweise auch nicht “zu klein”), damit jeder Ball zuverlässig ins Spiel läuft.\n\n3. Code Style:\n- In `PongGame.java` fehlen `package ...;` und `public static void main(String[] args)` (du hast `void main()` auf Top-Level ohne Klasse gezeigt); achte darauf, dass die Abgabe als normales Java-Programm kompilierbar ist (Klasse + main-Signatur).\n- Sehr viele `public` Felder in `Ball`/`Player`; üblich wäre Kapselung (private) und Methoden fürs Bewegen/Zeichnen/Kollisionen, damit `PongGame` nicht überall direkt auf internem Zustand rechnet.\n- Viele “Magic Numbers” (10, 780, 15, 4000, Radius 5, Paddle-Breite 10); als `static final` Konstanten benennen macht das leichter wartbar und vermeidet Fehler bei Änderungen.\n- `toString()` in `Player` wird nirgends genutzt; entweder einsetzen oder weglassen, um die Klasse fokussiert zu halten.\n- `new Random()` wird in `Ball` und `resetBall` jedes Mal neu erzeugt; besser eine Random-Instanz wiederverwenden (z.B. als Feld oder statisch), damit der Code klarer und effizienter ist.\n\n\n# Exercise: stepstats\n\n1. Correctness \n- Die geforderte Verwendung nennt das Attribut `averageSteps`, im Aufgabentext steht aber `double avgSteps = stats.averageSteps;` und gleichzeitig im vorgegebenen Nutzungscode `double avgSteps = stats.averageSteps;` – bei dir passt das, aber die Aufgabenbeschreibung zeigt auch `stats.averageSteps` vs. Beispiel `stats.avgSteps`; falls die Tests/Checker exakt `avgSteps` erwarten, würde dein Feldname nicht passen. \n- `StepTracker` entspricht noch nicht der vorgegebenen Struktur einer Java-Klasse mit `public static void main(String[] args)` und Package-Deklaration; so wie es dasteht, ist es nicht das gleiche „Client-Code“-Format wie in der Vorlage/Beispiellösung.\n\n2. Suggestion \n- Prüfe in der Aufgabenstellung bzw. in den Tests/der restlichen Vorlage, ob das Feld wirklich `averageSteps` heißen soll oder ob `avgSteps` erwartet wird, und richte den Attributnamen danach aus. \n- Vergleiche deine `StepTracker`-Datei mit der ursprünglichen Vorlage: Achte darauf, dass Signatur und Einbettung (Klasse, `main`, `package`, Imports) genau so sind, wie es im Projekt erwartet wird.\n\n3. Code Style \n- In `computeStatistics` überschattest du die Instanzfelder (`successDays`, `minSteps`, `maxSteps`) mit lokalen Variablen gleichen Namens; das ist zwar funktional, aber leicht verwirrend – überlege, entweder andere lokale Namen zu nehmen oder direkt mit `this.` zu arbeiten. \n- `computeStatistics` ist als `public` Methode von außen aufrufbar; da laut Aufgabe die Berechnung im Konstruktor passieren soll, wäre es stilistisch naheliegend, diese Methode nicht als Teil der öffentlichen API anzubieten (z. B. „nur intern“). \n- `StepTracker` nutzt `IO.println/print`, aber im Beispiel wird `System.out` verwendet; falls `IO` nicht Teil der Vorlage ist, wirkt das wie ein Fremd-Dependency.\n",
"status" : "SUCCESS"
}
}