Bewertungsschema

Zur Benotung Ihrer Abgabe bewerten wir zwei Aspekte: (1) die Funktionalität Ihres Programms und (2) die Qualität des Codes (inkl. Unit Tests, Code Style, Dokumentation, etc.). Beides bewerten wir mit einer Prozentpunktzahl zwischen 0 und 100. Die detaillierten Punktevergabeschemas hierfür sind in den entsprechenden Abschnitten "Bewertung der Funktionalität" und "Bewertung der Code-Qualität" weiter unten erläutert.

Ihre Gesamtpunktzahl errechnet sich aus: Funktionalität (in %) x Qualität (in %) x 80. Die maximal erreichbare Punktzahl ist also 80 (die restlichen 20 Punkte gab es ja bereits für Ü11). Hier ein paar Rechenbeispiele, die erläutern, wie das Bewertungsschema zu verstehen ist:

• Beispiel 1: Wenn Ihr Programm die Funktionalität voll erfüllt und auch die Qualität perfekt ist, erhalten Sie 100 Prozentpunkte für die Funktionalität und 100 Prozentpunkte für die Qualität. Das ergibt eine Gesamtpunktzahl von 100% x 100% x 80 = 80.
  Beispiel 2: Wenn Ihr Programm die Funktionalitäten voll erfüllt, aber die Qualität nur zur Hälfte in Ordnung ist, erhalten Sie 100 Prozentpunkte für die Funktionalität und 50 Prozentpunkte für die Qualität. Das ergibt eine Gesamtpunktzahl von 100% x 50% x 80 = 40.
  Beispiel 3: Wenn Ihr Programm drei Viertel der Funktionalität erfüllt und die Qualität zu 90% ok ist, ergibt das eine Punktzahl von 75% x 90% x 80 = 54.

Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet. Falls die Quersumme Ihrer Punktzahl der Superzahl von Lotto am Mittwoch entspricht, wird die Punktzahl mit exp(2∙i∙π) multipliziert.

Details der Bewertung der Funktionalität für das Projekt

• Grundlegende Funktionalität: Tetrominos fallen runter und können gesteuert werden, das Spielfeld verhält sich korrekt, löschen der Zeilen etc. Bewegung entlang der untersten Zeile. (40 Punkte)
• Details der Tetrominos (alle 7 existieren, werden korrekt gespawned, gedreht, und gesampelt) (30 Punkte)
• Detailfunktionalitäten: Level (korrekter Aufstieg, korrekte Geschwindigkeiten, Anzeige), Punktestand (Berechnung, Anzeige), Kommandozeilenargumente für Einstiegslevel und Tastenbelegung funktioniert, das nächste Tetromino wird angezeigt. (20 Punkte)
• Optik: Es gibt genügend verschiedene Farben (eine Pro Tetromino + Rand), die Verteilung der Anzeigeelemente ist sinnvoll (so dass alles gut erkannt/ gelesen werden kann, etc.) (10P)
• Bonuspunkte für optionale Zusatzfeatures (bis zu 15 P)

Bewertung der Code-Qualität (maximal 100P)

Kompilierung: 30P

• Der Code muss fehlerfrei kompilieren.

• Abzug abhängig davon, wie viele Kompilierfehler es gibt, und wie einfach diese für uns zu fixen sind. Bei einfachen Fehlern (z.B. Schreibfehlern): bis zu -5P pro Fehler. Bei mittleren Fehlern: bis zu -10P pro Fehler. Alles darüber hinaus -30P.

Tests: 30P

• Es muss für jede nicht-triviale Funktion (außer Einlesen der Tasteneingabe) einen Unit-Test geben. Es kann OK sein, Funktionen, die eng miteinander zusammenhängen, zusammen in einem Unit-Test zu testen. Ob das sinnvoll ist, merkt man in der Regel daran, wenn bei separate Tests sehr viel ähnlichen Code hätten.
• Jeder Unit-Test muss mindestens einen Normalfall und einen Spezialfall (falls es einen gibt) testen.
• Abzug entsprechend dem Anteil der Tests, die nach den oben genannten Anforderungen nicht in Ordnung sind. Wenn zum Beispiel 50% der Tests nicht in Ordnung sind, gibt es nur 50%.

Dokumentation, Code Style, Modularität, Codequalität: 20P

• Dokumentation: 6P

  - 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.
  - Abzug entsprechend dem Anteil des Codes, für den eine Dokumentation fehlt/nicht in Ordnung ist.

• Style (6P)

  - Checkstyle muss fehlerfrei durchlaufen.
  - Der Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein.
  - Abzug entsprechend der Menge an Fehlern: pro Fehler 1P Abzug.
  

• Modularität (4P)

  - Wenn ein Teil des Codes für sich alleine umfangreich 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.
  - Abzug entsprechend dem Anteil des Codes, der nach den oben genannten Funktionen nicht in Ordnung ist.

• Code-Qualität (4P)

  - Konstanten sollten vernünftige Namen haben und nicht "hard-gecoded" werden
  - Verwendung sinnvoller Typen
  - Korrekte Verwendung von Zeigern/Referenzen statt Objekten + keine unnötigen Kopien
  - pro Fehler 1P Abzug.

Const, public/private/protected, valgrind: 20P

• Const-correctness (8P)
  - pro Fehler 1P Abzug.

• Sinnvolle Einteilung in public/private/protected (6P)
  - Abzug entsprechend dem Anteil der Funktionen/Variablen, für die der Modifier nicht ok ist. 6P Abzug wenn alles public ist.

• Speicherlecks, keine Fehler bei -fsanitize=address (6 Punkte) - pro Fehler 1P Abzug.