## 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 weiter unten (''"Bewertung der Funktionalität"'') 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'''.'' <<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 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) <<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 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.'' <<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'' <<BR>>
 - ''Verwendung sinnvoller Typen'' <<BR>>
 - ''Korrekte Verwendung von Zeigern/Referenzen statt Objekten'' <<BR>>
 - ''Abzug.'' <<BR>>

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