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 (as is generally true for rules and regulations).
Rules for the programming exercise sheets
1. Programming language We exclusively use Python (version 3.10 or newer) 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, the ease of use of Python will allow us to focus on the actual topic of this course: information retrieval. Other programming languages are not allowed.
2. Versioning The version relevant for feedback is 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 with the targets compile, checkstyle, test and clean. We will provide the Makefile you should use in the template for each exercise sheet (see public/templates). 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 take care that no unnecessary files are uploaded, for example .pyc files. Many exercise sheets work with a dataset and some of the datasets are quite large. You must not upload these datasets to our SVN or terrible things will happen. Of course, small files used by unit tests can and should be uploaded.
5. Compilation The compile target must run through without errors, otherwise your exercise sheet will not be given feedback. The reason is that it requires an unreasonable effort from a tutor to understand and check code that does not even compile. If you encounter compilation problems, which you cannot fix yourself, please ask on the forum, see Item 9. Note that although Python is interpreted, the compile target will check whether the code is free from syntax errors. Intermediate versions (see Point 2) don't have to run through without errors.
6. Tests If tests are provided by us, you must not change them. If you change the contents of a test, you will not get any feedback for the corresponding part of your code. Exceptions are small and purely syntactic changes or if we have made a mistake. So it's better to fail a given test than to wrongly modify it so that it passes. You are free to add more tests, but you don't have to.
7. Checkstyle Your code should be free from checkstyle errors. Please note that checkstyle errors are easy to fix because the error messages from the checkstyle scripts are very concrete.
8. Readability Please write modular and easily comprehensible code. If a part of your code is large or complex enough or it is used in several places, it belongs into an own function. If the functionality of a code block is not obvious, there should be a comment explaining it. Explanations should always be concise and comprehensible. Often, an example is easier to understand (and shorter) than an abstract explanation.
9. Forum If you encounter any problems with your code, first try to find a solution yourself. Very often, a Google search of the error message leads you to a solution quickly. However, don't spend too much time on such problems: if you can't resolve a coding problem yourself after, say 5-10 minutes, don't hesitate to ask on the forum. Here are instructions for properly asking questions on the forum.
10. Submission In contrast to previous versions of this course, completing the exercise sheets is optional. If you decide to work on a sheet make sure to add a statement asking for feedback in your ''experiences.md''. In this statement specify to which degree and on which parts of the sheet you want feedback. Any submissions without such a statement will be ignored. This is to avoid that you submit just for the sake of submitting something and saving the tutors from unnecessary work. You will still receive feedback based on a point system for a better assessment of your performance, but you don't need to achieve a minimum number of points or have a minimum number of submissions to participate in the final exam.
11. Collaboration You are welcome to think about, discuss, and submit the exercise sheets together. If you decide to work as a group, make sure that only one of you submits your solution to the exercise sheet and indicate with whom you worked together. Copying code – whether from another person or group, the master solution from a previous edition of the course, or the internet – counts as plagiarism with the corresponding consequences. You don't learn anything by copying and it is unfair towards the majority of the participants who put a lot of effort into working on the exercise sheets. You may use the code we provide in the SVN of the course (like the code from the lecture or the master solution for a previous exercise sheet). Note however, that the master solutions we provide after the deadline for each sheet are strictly for your personal use only. Under no circumstances may you pass them on to others or let others access them from your machine. Not now and especially not in the future.
Rules for the theoretical tasks
1. For the submissions for theoretical tasks, Item 10 and 11 hold correspondingly.
2. The points are divided as follows: For a meaningful basic approach you get 40% of the points. For correctly worked out details you get 60% of the points. The reason for this division is that it's important to work out the details. A vague description of an idea is a start, but provides no certainty concerning correctness.