Bewertungsschema
Zur Benotung Ihrer Abgabe bewerten wir zwei Aspekte: (1) Die Funktionalität Ihres Programms und (2) die Qualität des "Drumherums" (Unit Tests, Code Style, Valgrind, etc.). Die Funktionalität bewerten wir mit einer Punktzahl zwischen 0 und 80. Das detaillierte Punktevergabeschema hierfür ist im Abschnitt "Bewertung der Funktionalität" weiter unten erläutert. Die Qualität des Drumherums bewerten wir mit einem Faktor zwischen 30% und 100%. Dieser Faktor ist als prozentualer Anteil des Drumherums, das in Ordnung ist, zu verstehen. Beispielsweise bedeutet ein Faktor von 50%, dass die Hälfte des Drumherums in Ordnung ist. Wie sich dieser Faktor genau zusammensetzt, ist ebenfalls weiter unten ("Bewertung des Drumherums") erläutert.
Die Gesamtpunktzahl errechnet sich aus Punktzahl * Faktor. Die maximal erreichbare Punktzahl ist also 80 (die restlichen 20 Punkte gab es bereits für Ü11). Hier ein paar Rechenbeispiele, die erläutern, wie die Bewertung zu verstehen ist:
Wenn Ihr Programm alle Funktionalitäten erfüllt und auch das Drumherum perfekt ist, erhalten Sie 80 Punkte für die Funktionalität und einen Faktor von 100% für das Drumherum. Das ergibt eine Gesamtpunktzahl von 80 * 100% = 80.
Wenn Ihr Programm alle Funktionalitäten erfüllt, aber das Drumherum nur zur Hälfte in Ordnung ist, erhalten Sie 80 Punkte und einen Faktor von 50%. Das ergibt eine Gesamtpunktzahl von 80 * 50% = 40.
Wenn Ihr Programm nur ¾ der Funktionalitäten erfüllt und 90% des Drumherums in Ordnung ist, ergibt das eine Gesamtpunktzahl von 60 * 90% = 54.
Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet.
Bewertung der Funktionalität
Projekt 1 (80 Punkte)
- Spiellogik (25 Punkte)
- Korrekte Implementierung der Bewegungen (inkl. der genannten Spezialfälle): 20P (5P pro Richtung)
- Korrektes Hinzufügen der zufälligen Kacheln zu Beginn des Spiels und nach jedem Zug: 5P - Bedienung über Pfeiltasten (6 Punkte)
- Korrektes Verhalten nach Drücken der Pfeiltasten: 4P (1P pro Pfeiltaste)
- Korrektes Verhalten nach Drücken von "ESC": 1P
- Korrektes Verhalten nach Drücken von "n": 1P - Punktzahl (5 Punkte)
- Berechnung: 3P
- Anzeige: 2P - Anzahl Züge (4 Punkte)
- Berechnung: 2P
- Anzeige: 2P - Spiel gewonnen (4 Punkte)
- Berechnung: 2P
- Anzeige: 2P - Spiel verloren (4 Punkte)
- Berechnung: 2P
- Anzeige: 2P - Undo Funktion (12 Punkte)
- Wenn Undo nur mit festem (hartgecodetem) Wert funktioniert:
- Behandlung Tastendruck: 1P
- Logik: 1P
- Wenn Undo mit variablem Wert funktioniert:
- Einlesen des Parameters von Kommandozeile: 3P
- Behandlung Tastendruck: 1P
- Logik: 8P
- Grafik (20 Punkte)
- Farbliche Markierung der Kacheln (mit unterschiedlichen Farben pro Wert): 8P
- Quadratische Kacheln: 3P
- Abstand der Kacheln zueinander: 3P
- Anzeige Wert einer Kachel: 2P
- Geeignete Größe der Kacheln: 2P
- Konsistentes Erscheinungsbild im gesamten Spielverlauf: 2P
Projekt 2 (80 Punkte)
Die Punktzahl ergibt sich aus dem in den Projektspezifikationen beschriebenen Punkteschema (pro Instanz des Benchmarks "größte Kachel / 2048" Punkte). Die insgesamt erreichte Punktzahl wird Ihnen nach einem Durchlauf des Benchmarks unten links (in der letzten Zeile) angezeigt. Anmerkung: Wenn Sie eine Punktzahl > 80 erreichen, bekommen Sie trotzdem nur 80 Punkte.
Bewertung des "Drumherums"
Fixer Faktor (30%)
Tests (30%)
- Es muss für jede nicht-triviale Funktion einen einzelnen Test geben.
- Als trivial gelten nur ganz einfache Funktionen wie getter und setter.
- Jeder Test muss mindestens einen Normalfall und einen Spezialfall (falls es einen gibt) testen.
- Als Spezialfall gelten solche Fälle, die in der Praxis nur selten auftreten (aber trotzdem auftreten können). Beispiele für Spezialfälle bezogen auf 2048: (1) Benutzer drückt undefinierte Taste; (2) Benutzer möchte einen Zug ausführen, der nicht möglich ist; (3) Beim Hinzufügen einer zufälligen Kachel ist das Feld bereits voll (es ist also kein Platz mehr für die Kachel).
- TODO: Insgesamt Punkte entsprechend dem Anteil der Tests, die entsprechend der oben genannten Anforderungen in Ordnung sind. - TODO: Beispiele: Wenn 50% der Tests in Ordnung, dann 15 %.
Doku, Style, Modularität, Codequalität (20%)
- Doku (30%)
- Jede Funktion muss dokumentiert sein.
- Zu jedem Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, muss es einen Kommentar geben.
- XXX entsprechend dem Anteil der Dokumentation, die in Ordnung ist (wenn z.B. nur die Hälfte der Funktionen dokumentiert sind, gibt es nur 15%).
- Style (30%)
- Checkstyle muss fehlerfrei durchlaufen
- Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein.
- Abzug entsprechend TODO
- Modularität (20%)
- Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder mehrfach benötigt wird, muss er in einer geeigneten Funktion stehen.
- Der Code für die Logik und die Grafik muss logisch voneinander getrennt sein.
- Code-Qualität (20%)
- Kein unnötiger Hardcode
- Verwendung sinnvoller Typen
- Korrekte Verwendung von Zeigern/Referenzen statt Objekten
- Abzug.
Const, public/private/protected, valgrind (20%)
- Const-correctness (40%)
- Sinnvolle Einteilung in public/private/protected (30%)
- Speicherlecks, valgrind (30%)