This page describes in detail how your submission should be structured and written (the style of your code) and how your points are calculated based on the grading scheme. It's normal if some keywords and concepts are still unknown to you. However, don't forget to review these guidelines regularly, especially before the final submission of an assignment. In contrast to ESP, grading schemes for OOP1 vary for each assignment.
The grading scheme is based on the scheme in ESP, in particular the sections on functionality, deductions and code quality. New or changed sub-chapters are highlighted in bold with the description "NEW"
<aside> ✅ A1, A2 A large part of your points are based on the functionality of your solution. We will test your submissions automatically. Your program will be tested in different scenarios (e.g. with different user inputs). We call these scenarios test cases. For each test case we will compare the return value of your program (and/or the output your program produces) with the correct values. If your program returns the correct value (and/or the correct output), the test case is considered as passed, otherwise, the test case is considered as failed. The points for the functionality result from the percentage of passed test cases.
$$ functionality\;points = \frac{number\;of\;passed\;testcases}{total\;number\;of\;testcases} $$
But don't worry, you also get the test system that already includes some test cases. This allows you to test your solution at any time and generate a test report. This test report shows which test cases already work and why you do not pass some test cases. So you get
But beware! We will not only test your submissions with the test cases we provide you. We will test your submission with more test cases after the deadline. Approximately half of all test cases are public, the others are secret. We also call the secret test cases private test cases. The public and private test cases together determine how many points you get for functionality. However, points can be deducted if you do not meet our specifications. More information about this can be found at Deductions.
An essential aspect is the proper handling of the memory. This is your responsibility as a programmer. Since errors in this area can lead to serious problems in your program, it is important to work properly here. If your program causes problems that can be traced back to incorrect memory management, each passed test case in which such a problem occurs will only be counted as 25%.
However, we do not want, for example, a bug in the code that leads to a memory management problem in every test case to immediately result in a deduction of 75% of the points for functionality. That would be a very high penalty and therefore the deduction is capped so that a maximum of 25% of the points for functionality can be deducted due to memory management issues.
</aside>
<aside> 💯 A1, A2, and A3
<aside> ℹ️ The combination of functionality points and code quality points serves as the basis for your final points. However, please note that we have some additional specifications that you must follow. The list below highlights problems that should be avoided because their use would result in point deductions. This is not done to punish, but it is necessary for us to be able to run a course with more than 600 students and at the same time teach you how to write effective and good code. We distinguish between 4 types of deductions. Depending on the problem, we deduct -10%, -25%, or even -100% of your points. If more than one problem occurs in your submission, deductions can be summed up. So read them carefully and keep them in mind while developing your solution.
</aside>
</aside>
<aside> 💯 A1: How do you get your points?
<aside> ✅ In A1 the Code Style category is omitted and 100% of the points are determined by functionality. However, this does not mean that code style is not important. If the code is difficult to read, we reserve the right to deduct up to 25%. More details can be found at Deductions. Your submission’s total points are calculated using this formula:
$$ functionality\;points - deductions = final\;points $$
Furthermore, there are no assignment interviews after A1, but the results from A1 will be used to divide you into groups. Of course, you can also select a group on your own (with your colleagues).
</aside>
</aside>
<aside> 💯 A2: How do you get your points?
<aside> ✅ Your submission's total points are calculated using this formula:
$$ functionality\;points + code\;quality\;points + effective\;programming\;points - deductions = final\;points $$
Details about the Deductions are described above. Now let's have a look the other components:
</aside>
</aside>
<aside> 💯 A3: How do you get your points?
<aside> ✅ For Assignment 3, the style will not be evaluated. The functionality will also not be assessed based on "traditional" test cases but according to a schema defined in the Assignment 3 instructions. A3 is an extension of A2 and can therefore only be done if your A2 solution works properly, otherwise, you have the option to improve your version of A2 during this phase.
</aside>
</aside>