## page was renamed from ProgrammierenCplusplusSS2020/Projekt/Korrekturschema
#acl Claudius Korzen:read,write -All:read 

= 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 Maß für den prozentualen Anteil des Drumherums, der in Ordnung ist, zu verstehen. Wie genau wir diesen Faktor berechnen, ist im Abschnitt ''"Bewertung des Drumherums"'' weiter unten erläutert.

Ihre Gesamtpunktzahl errechnen wir 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 das Bewertungsschema 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'''.'' <<BR>>
 * '' 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'''.'' <<BR>>
 * '' Wenn Ihr Programm nur ¾ der Funktionalitäten erfüllt und 90% des Drumherums in Ordnung ist, ergibt das eine Punktzahl von '''60 * 90% = 54'''''.

Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet.

== Bewertung der Funktionalität ==

Für die Funktionalität Ihres Programms bekommen Sie maximal 80 Punkte. Im Folgenden ist zuerst das Punktevergabeschema für Projekt 1 und danach das Punktevergabeschema für Projekt 2 erläutert. 

=== 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
 * Aktuelle Punktzahl (5 Punkte)
 - ''Korrekte Berechnung:'' 3P <<BR>>
 - ''Anzeige:'' 2P
 * Anzahl Züge (4 Punkte)
 - ''Korrekte Berechnung:'' 2P <<BR>>
 - ''Anzeige:'' 2P
 * Spiel gewonnen (4 Punkte)
 - ''Korrekte Berechnung:'' 2P <<BR>>
 - ''Anzeige:'' 2P <<BR>>
 - ''Wenn Spiel nicht weiter spielbar ist:'' -1P
 * Spiel verloren (4 Punkte)
 - ''Korrekte Berechnung:'' 2P <<BR>>
 - ''Anzeige:'' 2P
 * Undo Funktion (12 Punkte)
 - ''Wenn Undo nur mit festem (hartgecodetem) Wert funktioniert:'' <<BR>>
  - ''Korrekte Behandlung Tastendruck:'' 1P <<BR>>     
  - ''Logik:'' 1P
 - ''Wenn Undo mit variablem Wert funktioniert:'' <<BR>>
  - ''Einlesen des Parameters von Kommandozeile'': 3P <<BR>>     
  - ''Korrekte 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" ==

Die Qualität des Drumherums bewerten wir mit einem Faktor zwischen 30% und 100%. Im Folgenden erläutern wir, wie wir diesen Faktor berechnen. Die angegebenen Prozentzahlen sind additiv zu verstehen, wenn Sie zum Beispiel nur Tests geschrieben haben, und die perfekt sind, bekommen Sie einen Faktor von 30% (der fixe Anteil) + 30% (für die Tests) = 60%.

=== Fix (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).''
 * Punkte entsprechend dem Anteil der Tests, die entsprechend der oben genannten Anforderungen in Ordnung sind. Wenn zum Beispiel 50% der Tests in Ordnung sind, gibt es nur die Hälfte der Punkte (relativ zu den 30%, also 15%).

=== Doku, Code 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>>
 - Punkte entsprechend dem Anteil der Dokumentation, die in Ordnung ist. <<BR>>
 * Style (30%)
 - Checkstyle muss fehlerfrei durchlaufen <<BR>>
 - Der Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein. <<BR>>
 - Punkte entsprechend der Menge an Fehlern: pro Fehler 10% Abzug (relativ zu den 30%; max. 100% Abzug).<<BR>>
 * Modularität (20%)
 - Wenn ein Teil des Codes für sich alleine umfangreich 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>>
 - Punkte entsprechend dem Anteil des Codes, der in Ordnung ist. 
 * Code-Qualität (20%)
 - ''Kein unnötiger Hardcode'' <<BR>>
 - ''Verwendung sinnvoller Typen'' <<BR>>
 - ''Korrekte Verwendung von Zeigern/Referenzen statt Objekten'' <<BR>>
 - Punkte entsprechend der Menge an Fehlern: pro Fehler 10% Abzug (relativ zu den 20%; max. 100% Abzug).

=== Const, public/private/protected, valgrind (20%) ===
 * Const-correctness (40%)
 * Sinnvolle Einteilung in public/private/protected (30%)
 * Speicherlecks, valgrind (30%)