# Introduction to the Assignments

The practical assignments are split into [Mandatory Assignments](mandatory-assignments) (1 - 2) and [Extra Assignments](extra-assignments) (3-a, 3-b and above). **Passing the mandatory assignments is a requirement for passing the course** but also rewarded with **500 points**. The extra assignments are fully optional, but add up to maximum of **4,150 points!!**

{% hint style="warning" %}
Do not get discouraged by the perceived difficulty of the first few assignments. Low-level languages like Assembly have a very steep learning curve. Even trivial things may seem very challenging. Once you are finished with the fourth assignment, the things that you have struggled with for the first assignment will likely seem trivial to you.
{% endhint %}

***

## Framework

The assignments need to be solved by extending the skeleton files given as part of the framework. If you have not yet created your own (private) GitHub repository from the given framework template, follow the [GitHub Repository Guide](../setup-guides/github-repository-setup) to do so. Furthermore, make sure you are familiar with the `README.md` file given as part of the framework and have followed all setup steps.

{% hint style="danger" %}
All assignment files have some preambles of the form:

```c
#ifdef MACOS
    ...
#else
    ...
#endif
```

**Do not edit these parts of the files**! Otherwise, your program might no longer work with the automated tests on CodeGrade or might be rejected by a TA during hand-in.

Furthermore, you **may only use the library functions that are listed in this preamble for the specific assignment**. Using additional library functions (e.g., `exit`) will result in your submission being rejected during hand-in.
{% endhint %}

***

## Assignment Setup

The description for each assignment can be found on the corresponding page of this Lab Manual. That description explains what has to be done and in what manner. If that description leaves out any information that you feel you need, make sure to ask a TA for clarification before you start implementing.

For most assignments, the functionality of your solution is tested through an extensive testing framework on CodeGrade. Make sure to have a look at the expected behavior of your program!

{% hint style="warning" %}
The tests on CodeGrade are **subject to change** for the duration of the Lab (e.g., for mitigating newly discovered issues).

However, if your assignment was handed in and approved, the **grade will stay** even if some newly added or changed tests no longer pass.
{% endhint %}

Most assignments ask you to implement a certain function or set of functions. The tests do not only test your program as a standalone (i.e., by using your `main` routine) but also test the individual parts on their own. You must thereby carefully follow both the requirements from the assignment description and the calling conventions to pass those tests.

{% hint style="info" %}
You have **unlimited attempts to submit on CodeGrade**. While it may not be the approach recommended by us (partly due to the large time overhead with submitting on CodeGrade), you are free to follow an iterative, error-driven approach to solving the assignments.
{% endhint %}

***

## Handing In

{% hint style="warning" %}
If you are working in a group with a partner, make sure you have **followed all steps as indicated on Canvas for setting up your group on CodeGrade** before uploading and handing in an assignment.
{% endhint %}

To hand in your submission, there are multiple steps required:

1. Upload your submission to CodeGrade and check for the completion of the automated tests. (This step can be done at any time, so not necessarily during a Lab session)
2. Once your submission passes **all** tests, enter the submission queue during a Lab session.
3. Have your work checked (and hopefully approved) by a TA.

As the functionality of your program is mostly automatically tested through CodeGrade, the sign-off with a TA will not focus on that aspect (but may include some additional checks for some assignments). The in-person sign-off will test your understanding of the program you submitted. It may include questions about the technical details, design decisions, or general program flow, to name a few. The TA may ask you to illustrate your development process and check the commit history of your Git repository.

{% hint style="success" %}
Make sure to **prepare for the sign-off**. That means being knowledgeable about all parts (even if they were written by your partner) of your solution, possibly adding further comments to help your explanation, and making sure that any leftover pieces of code from previous approaches are properly removed.
{% endhint %}

***

## Grading

{% hint style="warning" %}
Points are only given for **fully complete submissions** accepted during hand-in by a TA, there is no partial grading (unless indicated otherwise).
{% endhint %}

The grading does not only encompass functionality (i.e., passing all the tests) but also your ability to explain your solution and the style of your code. Code style includes (but is not limited to) the structure of your program as well as the presence of explanatory comments - have a look at the [Running Example](../reference-documentation/a0-a-running-example) to get an intuition about the style we expect.

If any of these parts are insufficient, the grading TA will reject your submission and you will have to resubmit after eliminating the named issues.
