Requirements for code and reviews

AI in code and review

It is in no way mandatory but OK to use AI tools to help you write code, but it is not OK to blindly copy and paste results from AI tools without understanding it. All code that was written using AI tools must be marked in a way it is clear to the reviewer that it was written with the assistance of AI. This policy also extends to your responses in the review process. This is to make the review process clearer and to guide your usage of AI tools. Remember, that posing others work (this includes undocumented usage of AI) as your own is plagiarism and is not acceptable.

As stated earlier, the goal is to learn and understand our work, not just to get something committed. AI tools have the power to create a huge amount of output. In the hands of an inexperienced developer this can lead to an excessive amount of code and load on reviewers. Just like you, the reviewers are humans who want to make the review process as smooth and quick for you as possible so lets work towards that together.

If an instructor is in suspecting that non-compliant code was submitted for review, be prepared to explain the intricacies of the code and how it works. Be also aware that I expect the answers to come from you, not an AI tool. If you are unable to explain and rectify these issues in the code, the review will not pass, you will not get points for the tasks and any tasks utilising this code can not be completed. Additionally, repeated bad-faith usage of AI tools can be escalated to the academic fraud committee.

We put a lot of faith in you as students to act responsibly and do your due diligence while using AI tools. If you are unsure about how to mark code that was written with AI assistance, please ask an instructor for guidance.

Below are some examples of marked code. The examples are using Python but how exactly and in what language you do it is up to you, as long as it is clear to the reviewer that the code was written with AI assistance.

# AI generated function
# It is a important function that takes in two arguments and returns a boolean value.
def ai_generated_function(arg1: int, arg2: str) -> bool:
    return True

# AI generated code START
A: int = 1
B: str = "Hello World"

# My custom stuff not written by AI
def my_custom_function() -> None:
    print("This function does something useful.")

def useless_function() -> None:
    print("This function does nothing useful.")

useless_function()
# AI generated code END

Created Merge Requests should be small in scope

To make Merge Requests as smooth as possible let’s keep one MR-s scope to one task.

If multiple tasks are combined into one MR it becomes hard to review due to the sheer scope of changes. This increases the time a review takes. Additionally, it is harder for the codes author to fix issues since systematic mistakes can be repeated more, creating more places needing fixing.

Follow PEP 8 coding conventions

Let’s follow PEP 8 coding conventions when writing code. They can be found here: https://peps.python.org/pep-0008/. This allows us to unify coding conventions and write better-to-read that can be understood faster by more people.

Use python logging instead of "print(…​)" in final code

While printing stuff to console is a simple approach to get fast results it is hard to fine tune and configure later on without changes in code. This becomes a real issue when the project grows, and it is needed to enable or disable printing for debugging purposes or gaining the few percentage points of performance you need by disabling all logging during a competition.

print("Something happened!") # BAD

logger.info("Something happened!") # GOOD

TL;DR: Logging seems like a lot of effort but it simple to set up and allows for better configurability that improves code debugging and performance when utilising the tools correctly.