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 und vor allem sich an der Vorgabe hält (wenn wir spezifieren was der Algorithmus ist, dann wollten wir auch diesen Algorithmus sehen).

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

• Vorgegebene Tests: diese müssen durchlaufen. Bei kleineren Fehlern: -5P. Bis mittleren: -10P. Alles drüber: -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.