# Rules and Regulations

This appendix states the rules and regulations to which you need to adhere in order to have your assignments approved. These rules effectively apply to all Lab courses, but to avoid any confusion, they are stated here explicitly for this course.

***

## Necessary Conditions for Approval

To have your assignments approved, your work needs to meet all of the following conditions:

1. You need to deliver correct specifications.
2. Your finished code needs to be functionally correct.
3. Your code needs to be algorithmically correct.
4. Your code needs to be properly documented.

We stress that your work will not be considered fit for approval until you meet all four of these criteria. The details of what we consider to be correct in this context will be defined in the subsequent paragraphs.

### Correct Specifications

If an assignment so asks, you will need to hand in a correct specification for the specified part of the exercise. Specifications must be written in pseudocode. Pseudocode is code that resembles actual high-level (non-assembly) program code closely. It is called pseudocode because it does not necessarily have to be real, compilable code. A good, clear example of pseudocode is provided in Assignment 0. We expect your pseudocode to be similar in clarity, quality, and level of detail. Specifically, this means that your pseudocode must have:

* proper comments
* a clear and clean layout
* a simple, clearly understandable structure

We expect that you have your specifications checked before you start your implementation work. The TA may ask you to make changes to your specifications, so we strongly advise you not to start programming before having your specs approved. If you choose to ignore this advice, we do not accept responsibility for any wasted effort on your part.

### Functionally Correct Code

The source code that you hand in should be functionally correct. This is implied by the following:

* The source code must compile without errors or warnings.
* The program must function as specified in the assignment.
* The program must run to completion without runtime errors.

For most assignments, the functionality is largely tested automatically through CodeGrade. However, passing the tests does not mean that your program is necessarily functionally correct. The tests are only intended as an indication for you. A TA might still find functional flaws during the hand-in and reject your submission on the basis thereof.

### Algorithmically Correct Code

The programs that you hand in should be algorithmically correct. The correct algorithm is, by definition, the algorithm that was conveyed to you by the TAs during the approval of your specifications. Solutions that are functionally correct but do not follow the required algorithm will not be approved during hand-in.

### Compliance with Conventions

As explained in this Manual, a calling convention allows subroutines to interact through a common set of rules. Furthermore, other conventions, such as the use of a prologue and epilogue in each subroutine, make code easier to understand and reuse by others. We expect that all uses of subroutines in your code, both calling external subroutines and writing your own, adhere to the conventions laid out in this Manual.

### Properly Documented Source Code

All source code, including pseudocode, should be properly documented. For Assembly programming especially, comments in the source code are highly useful. Commenting source code is not an exact science, but at the least, we expect that you adhere to the following guidelines:

* **Natural language:** Comments should be written in a natural human language, which is preferably in English. We expect that you use the same language consistently. Pseudocode and overly complicated mathematical notations are not accepted as proper comments.
* **Continuity:** The comments in the body of your code should “tell the story” of the code in a concise, clear manner. If you strip away the accompanying source code, your comments should make up a compact description of the algorithm in acceptable prose. Do place your comments with care and avoid overly lengthy comments.
* **Subroutines:** Each subroutine should be accompanied by a clear description of its function. A description should also be given of the meaning and type of the arguments and the return value (the function signature).
* **Layout:** Part of the readability of source code comes from a good layout. We expect you to be precise and, most importantly, consistent in your style.

The program from assignment 0 contains good examples of properly commented assembly- and pseudocode. You should strive for the same level of quality. You are allowed (and encouraged) to develop your personal style of commenting and layout, but we expect that you will be precise and consistent. Sloppy comments or disturbing layouts will not be accepted.

***

## Deadlines

All relevant deadlines are given on the Canvas page of the course. Information should not be taken from the submission deadline indicated on CodeGrade (as the actual deadline differs based on your Lab group).

Please start early and also submit your assignments as early as possible. From experience, the Lab sessions get very busy in the weeks of the deadlines and you may need to be prepared for long wait times.

***

## Anti-Fraud Policy

Our anti-fraud policy is simple: **zero-tolerance** - at least within the limits set by the VU. We will pursue each case of potential fraud, and we will use the means provided by the university to punish any (attempted) fraud.

The following are some (but by far not all) cases that are considered fraud:

* Sending your code to other groups. The motivation of “I sent it for them to find some inspiration” does not work.
* Copying somebody else’s code. Changing the names of variables in someone else’s code and submitting the results is still considered fraud.
* Receiving help from someone, when the help amounts to letting that someone write your code.
* Renting the services of a programmer to solve the assignments for you.

If solutions are inspired by external sources (such as _Stack Overflow_), those sources need to be given explicitly!

### Generative AI

**Any use of generative AI (such as ChatGPT,** **or** **GitHub Copilot) is** <mark style="color:red;">**not permitted**</mark>**.** One of the goals of this Lab is for you to develop your skills for approaching complex problems and understanding theoretical concepts. A major part of this development happens through the (sometimes long and exhausting) process of struggling with problems that arise as part of these assignments. While we acknowledge that generative AI can be a powerful tool for explaining code or code snippets (if used wisely), the _shortcut_ through AI-generated explanations largely bypasses your learning and development process (and with that poses the question of why you would even want to follow this course).

Teaching Assistants will not help you with any questions about code that has been generated by AI. Furthermore, attempted hand-in of AI-generated code **will be reported to the examination board as attempted academic fraud** in accordance with [Regels en Richtlijnen (Rules and Guidelines), Art 19 & 20](https://assets.vu.nl/d8b6f1f5-816c-005b-1dc1-e363dd7ce9a5/8e52b8e0-78ae-4425-b97e-aef3a97c4e84/2023-2024%20Rules%20and%20Guidelines%20BETA.pdf). In such a case, you will not be allowed to hand in the assignment in question (which for the mandatory assignments means that you will **fail the course**) and the examination board will decide on the further consequences.
