AD Teaching Wiki
  • Comments
  • Immutable Page
  • Menu
    • Navigation
    • RecentChanges
    • FindPage
    • Local Site Map
    • Help
    • HelpContents
    • HelpOnMoinWikiSyntax
    • Display
    • Attachments
    • Info
    • Raw Text
    • Print View
    • Edit
    • Load
    • Save
  • Login

FrontPage

Links

  • Daphne

  • Forum

  • CodingStandards

  • Punkteschema

  • Anleitungen

  • Linux Image

  • 10 Gebote

Vergangene Semester

  • SS 2018

  • SS 2016

  • SS 2014

  • SS 2013 (nur ESE)

  • SS 2012

  • SS 2011

  • SS 2010

Revision 27 as of 2020-08-04 11:20:13
AD Teaching Wiki:
  • ProgrammierenCplusplusSS2020
  • Projekt
  • Bewertungsschema

Korrekturschema

# TODO: Multiplikative Bewertung erklären und sonst alles, was man zum Verstehen des Schemas wissen muss.

Bewertung der Funktionalität

Projekt 1

Projekt 2

Die Maximalpunktzahl bei Projekt 2 ergibt sich aus dem in den 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: Die maximal erreichbare Punktzahl beträgt 80. Wenn Sie eine Punktzahl > 80 erreichen, bekommen Sie trotzdem nur 80 Punkte.

Bewertung des "Drumherums"

Fixer Anteil (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 (z.B. F7); (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%)
  • Style (30%)
  • Modularität (20%)
  • Codequalität (20%)

Const, public/private/protected, valgrind (20%)

  • Const-correctness
  • Sinnvolle Einteilung in public/private/protected
  • Speicherlecks, valgrind
  • MoinMoin Powered
  • Python Powered
  • GPL licensed
  • Valid HTML 4.01