#acl Claudius Korzen:read,write -All:read 

= Bewertungsschema =

Sie können für das Projekt maximal 80 Punkte erreichen (die restlichen 20 Punkte gab es bereits für Ü11).
Die Berechnung Ihrer Punktzahl erfolgt in zwei Schritten. Im ersten Schritt wird die Funktionalität Ihres Programms bewertet. Sie erhalten hierfür maximal 80 Punkte. Das zugrundeliegende Bewertungsschema für diesen Schritt ist weiter unten ("Bewertung der Funktionalität") erläutert. Im zweiten Schritt wird das "Drumherum" (Tests, Style, valgrind, etc.) bewertet. Sie erhalten hierfür eine ''prozentuale'' Punktzahl, die mit der Punktzahl aus dem ersten Schritt ''multipliziert'' wird. Das Bewertungsschema für diesen Schritt ist ebenfalls weiter unten ("Bewertung des Drumherums") erläutert.

''Beispiele: ''

(1) Wenn Ihr Programm alle Anforderungen erfüllt und das Drumherum auch perfekt ist, erhalten Sie: '''80 * 100% = 80 Punkte'''. <<BR>>
(2) Wenn Ihr Programm alle Anforderungen erfüllt und das Drumherum nur zur Hälfte in Ordnung ist, erhalten Sie: '''80 * 50% = 40 Punkte'''. <<BR>>
(3) Wenn Ihr Programm nur ¾ der Anforderungen und 90% des Drumherums erfüllt, erhalten Sie '''60 * 90% = 54 Punkte'''. 

Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet. Die maximal erreichbare Punktzahl ist 80 Punkte (die restlichen 20 Punkte gab es bereits für Ü11).

== Bewertung der Funktionalität ==

=== Projekt 1 (80 Punkte) ===

 * Spiellogik (25 Punkte)
 - ''Korrekte Implementierung der Bewegungen (inkl. der genannten Spezialfälle):'' 20P (5P  pro Richtung) <<BR>>
 - ''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) <<BR>>
 - ''Korrektes Verhalten nach Drücken von "ESC":'' 1P <<BR>>
 - ''Korrektes Verhalten nach Drücken von "n":'' 1P
 * Punktzahl (5 Punkte)
 - ''Berechnung:'' 3P <<BR>>
 - ''Anzeige:'' 2P
 * Anzahl Züge (4 Punkte)
 - ''Berechnung:'' 2P <<BR>>
 - ''Anzeige:'' 2P
 * Spiel gewonnen (4 Punkte)
 - ''Berechnung:'' 2P <<BR>>
 - ''Anzeige:'' 2P
 * Spiel verloren (4 Punkte)
 - ''Berechnung:'' 2P <<BR>>
 - ''Anzeige:'' 2P
 * Undo Funktion (12 Punkte)
 - ''Wenn Undo nur mit festem (hartgecodetem) Wert funktioniert:'' <<BR>>
  - ''Behandlung Tastendruck:'' 1P <<BR>>     
  - ''Logik:'' 1P
 - ''Wenn Undo mit variablem Wert funktioniert:'' <<BR>>
  - ''Einlesen des Parameters von Kommandozeile'': 3P <<BR>>     
  - ''Behandlung Tastendruck:'' 1P <<BR>>     
  - ''Logik:'' 8P

 * Grafik (20 Punkte)
 - ''Farbliche Markierung der Kacheln (mit unterschiedlichen Farben pro Wert):'' 8P <<BR>>
 - ''Quadratische Kacheln'': 3P <<BR>>
 - ''Abstand der Kacheln zueinander:'' 3P <<BR>>
 - ''Anzeige Wert einer Kachel:'' 2P <<BR>>
 - ''Geeignete Größe der Kacheln'': 2P <<BR>>
 - ''Konsistentes Erscheinungsbild im gesamten Spielverlauf:'' 2P <<BR>>

=== Projekt 2 (80 Punkte) ===

Die Punktzahl ergibt sich aus dem in den [[https://ad-wiki.informatik.uni-freiburg.de/teaching/ProgrammierenCplusplusSS2020/Projekt|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 Anteil (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.'' <<BR>>
 - ''Zu jedem Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, muss es einen Kommentar geben.'' <<BR>>
 - ''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%).'' <<BR>>
 * Style (30%)
 - ''Checkstyle muss fehlerfrei durchlaufen'' <<BR>>
 - ''Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein.'' <<BR>>
 - ''Abzug entsprechend TODO'' <<BR>>
 * 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. <<BR>>
 - Der Code für die Logik und die Grafik muss logisch voneinander getrennt sein. <<BR>>
 * 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%)