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%)