Please read this page very carefully and completely before you start working on the first exercise sheet. The rules are valid for all exercise sheets of this course. Not knowing them will not protect you from consequences.
Rules for the programming exercises
1. Programming language We recommend Python for several reasons. First, we will also use Python in the lectures. Second, the code templates and unit tests will be provided in Python. Third, ease of use of Python will allow us to focus on the actual topic of this course: information retrieval. If you prefer, you may also use Java or C++ for the exercise sheet, but it will be more (and depending on the exercise sheet and your proficiency maybe much more) work. Other programming languages then the named three are not allowed.
2. Submission We will grade the last version which you have uploaded (committed) to our SVN before the deadline. You can upload as many intermediate versions (including for backup purposes) as you like. Submissions after the deadline or via email will not be accepted, so please start working on the sheets in time.
3. Makefile Each submission must have a Makefile (for Python and C++) or a build.xml (for Java) with the targets compile, checkstyle, test and clean. This was explained and demonstrated in Lecture 1 and an example file for each language is available under public/lecture-01/. Our continuous build system (Jenkins) will check automatically after each commit, whether the targets run through without errors. You can also initiate a check manually.
4. Uploading Please pay attention Achten Sie darauf, dass Sie keine unnötigen Dateien hochladen, zum Beispiel .pyc oder .o oder .class Dateien. Zu manchen Übungsblättern gehören (große) Datensätze. Diese dürfen erst recht nicht hochgeladen werden, sonst explodiert das SVN und wenn es ganz schlecht läuft das Universum.
5. Kompilieren Das compile target muss grundsätzlich fehlerfrei durchlaufen, sonst wird Ihr Code nicht korrigiert und es gibt keine Punkte. Grund dafür ist, dass nicht kompilierbarer Code sehr schwer zu durchschauen sein kann und dies unzumutbar viel Arbeit für die Tutor:innen wäre. Fragen Sie bei Problemen bitte rechtzeitg im Forum, siehe Punkt 9.
6. Tests Wenn Tests vorgegeben sind, dürfen diese nicht verändert werden. Wird der Inhalt eines Tests geändert, gibt es für diesen Teil des Programms keine Punkte. Ausnahme sind kleinere syntaktische Änderungen aus guten Grund oder wenn der Fehler bei uns liegt. Schlägt ein Test fehl, gibt es für diesen Teil des Programms maximal 50% der Punkte. Sie können unsere Tests gerne um zusätzliche Testfälle erweitern, das ist aber kein Muss.
7. Checkstyle Ihr Code sollte frei von checkstyle Fehler sein. Mit Checkstyle-Fehlern riskieren Sie einen Punktabzug bis zu 10% der Gesamtpunktzahl für eine Programmieraufgabe, bei sehr vielen Fehlern bis zu 20%.
8. Lesbarkeit Schreiben Sie modularen und verständlichen Code. Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder mehrfach benötigt wird, gehört er in eine eigene Funktion. Jedes Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, sollte erklärt werden. Die Erklärung sollte kurz und aussagekräftig sein. Manchmal ist ein Beispiel nützlicher (und kürzer) als eine abstrakte Erklärung. Für unverständlichen Code riskieren Sie ebenfalls einen Punktabzug von bis zu 20%.
9. Forum Wenn Sie ein Problem bei der Implementierung haben, suchen Sie ein paar Minuten (auf Google oder auch auf dem Forum, da wurden sehr viele Fragen schon mal gestellt) nach dem Fehler. Wenn Sie nicht fündig werden, fragen Sie gerne auf dem Forum, da wird Ihnen in der Regel schnell geholfen. Hier unsere Anleitung für das richtige Fragen auf dem Forum.
10. Zusammenarbeit Sie können gerne zusammen über die Übungsblätter nachdenken, aber der Code bzw. die Lösungen müssen zu 100% selber geschrieben werden. Auch das teilweise Übernehmen von Code, egal ob von einer anderen Person, der Musterlösung aus einer vergangenen Vorlesung oder aus dem Internet, gilt als Täuschungsversuch, mit den entsprechenden Konsequenzen. Wir müssen das so deutlich sagen, weil es in der Vergangenheit immer wieder vorgekommen ist. Man lernt nichts, wenn man Code bzw. Lösungen von anderen übernimmt und es ist unfair gegenüber dem Großteil der Teilnehmer:innen, die sich ehrlich Mühe geben.
Regeln für die theoretischen Aufgaben
1. Für die Abgaben zu den theoretischen Aufgaben gilt Punkt 10 von der Liste oben sinngemäß.
2. Für die Punktevergabe gelten folgende Leitlinien. Für eine sinnvolle Grundidee bzw. einen sinnvollen Ansatz gibt es 40% der Punkte. Für die ordentliche Ausarbeitung gibt es 60% der Punkte.