## page was renamed from ProgrammierenCplusplusSS2022/ProjektBewertungsSchema
#acl Hannah Bast:read,write Johannes Kalmbach: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 Codes (inkl. Unit Tests, Code Style, Valgrind, 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'''.'' <<BR>>
 '''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'''.'' <<BR>>
 '''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.

{{{
Hinweis: Die folgenden Aufteilungen und Punktzahlen sind vorläufig und können noch leicht angepasst werden.
}}}

== Bewertung der Funktionalität für Projekt 1 (maximal 100P = 100%) ==

Bestimmen, ob ein gegebener Ausdruck gültig ist gemäß Projektbeschreibung: 30P

Generieren einer (gemäß Projektbeschreibung) zufällig gewählten Gleichung: 10P

Eingabe einer Gleichung gemäß Projektbeschreibung: 20P

Grafische Darstellung des jeweils aktuellen Zustands: 30P

Sonstige Spiellogik: 10P

== Bewertung der Funktionalität für Projekt 2 (maximal 100P) ==

Erreichen der einfachen Durschnittswerte gemäß Projektbeschreibung: 80P

Erreichen der etwas besseren Durchschnittswerte gemäß Projektbeschreibung: 20P

== 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. Bei der Eingabe der Gleichung sollten alle in der Projektbeschreibung genannten Spezialfälle (für die Umsetzung der Pfeiltasten und von backspace) abgedeckt sein.
 * 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.'' <<BR>>
 - ''Zu jedem Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, muss es einen Kommentar geben.'' <<BR>>
 - ''Abzug entsprechend dem Anteil des Codes, für den eine Dokumentation fehlt/nicht in Ordnung ist.''
 * Style (6P)
 - ''Checkstyle muss fehlerfrei durchlaufen.'' <<BR>>
 - ''Der Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein.'' <<BR>>
 - ''Abzug entsprechend der Menge an Fehlern: pro Fehler 1P Abzug.''<<BR>>
 * 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.'' <<BR>>
 - ''Der Code für die Logik und die Grafik muss logisch voneinander getrennt sein.'' <<BR>>
 - ''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'' <<BR>>
 - ''Verwendung sinnvoller Typen'' <<BR>>
 - ''Korrekte Verwendung von Zeigern/Referenzen statt Objekten'' <<BR>>
 - ''pro Fehler 1P Abzug''.

'''Const, public/private/protected, valgrind: 20P'''
 * Const-correctness (8P) <<BR>>
 - ''pro Fehler 1P Abzug''.
 * Sinnvolle Einteilung in public/private/protected (6P) <<BR>>
 - ''Abzug entsprechend dem Anteil der Funktionen/Variablen, für die der Modifier nicht ok ist. 6P Abzug wenn alles public ist.''
 * Speicherlecks, valgrind (6 Punkte)
 - ''pro Fehler 1P Abzug''.