Im Gegensatz zu Frau Bast benutze wird eine additive Version: 50 von den 80 Puntke sind für die Funktionalität und die restlichen 30 gehen für die Code-Qualität.

Achtung: falls wir Code bekommen der kein C++ ist (z.B. alles inline Assembly oder in einer ander Sprache ist), dann behalten wir uns das Recht keine Punkte zu geben.

Bewertung der Funktionalität (5/8 von der gesamt Note)

Für die Bewertung werden wir den Fuzzer nutzen und den Checker und rauszufinden, ob die Implementierung korrekt ist.

Bewertung der Code-Qualität (3/8 von der gesammt Note)

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 Testeingabe) 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

• Es ist klar wo man beim lesen anfang soll und was die Main Dateien tun
• 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)

• 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
• 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, valgrind (6 Punkte)

• pro Fehler 1P Abzug.