Samarbete / lånad kod

Ni behöver vara medvetna om reglerna för samarbete och användning av fritt material, så att ni inte riskerar göra något som räknas som fusk eller vilseledande.

Följande regler gäller när man använder kod som man inte har skrivit själv (ensam eller tillsammans med en labbpartner registrerad i WebReg).

Användande av klassbibliotek i JAR-filer

När du använder klassbibliotek i kompilerat format (JAR-filer) finns ingen risk att vi misstar denna kod för din egen. Då gäller följande:

• Du får gärna använda alla klasser i standardbiblioteket för Java 21.

• Du får också använda MigLayout och GSON, som vi har refererat till under föreläsningar och/eller i labbarna, liksom Apache Commons CLI för tolkning av kommandoradsparametrar. Vi har redan lagt in dessa klassbibliotek som IDEA-libraries i projekten som vi skapar åt er.

• I projektet får du också gärna använda andra fullständiga klassbibliotek som du laddar ner från nätet, givet att du läser och följer varningarna nedan.

  Följ instruktionerna för IDEA, eller den enklaste varianten: "You can also create a new library from JAR files located within a project content root. Select these files in the Project tool window, and then select Add as Library from the context menu". Du behöver inte tala om för oss att du använder dessa välkända bibliotek.

  • Du ska inte använda verktyg som Maven eller Gradle för att automatiskt hantera beroenden på klassbibliotek. Verktygen är visserligen användbara, men ger merarbete för handledarna och sätter käppar i hjulen för vår kodinspektion. Se istället instruktionerna för IDEA för att se hur du lägger till nya bibliotek.

  • Klassbiblioteken får inte vara ramverk som "tar över" eller "kontrollerar" projektets struktur. Det måste vara din kod som ger den övergripande strukturen och som driver allt framåt, medan klassbiblioteket får hjälpa till med isolerade deluppgifter – t.ex. att hantera uppritning av rörliga figurer på skärmen eller att beräkna matrismultiplikationer.

  • Var försiktig med klassbibliotek som kan bero på hårdvara eller liknande. Ditt program behöver gå att köra även på t.ex. handledarnas datorer – på Linux, Windows och MacOS.

  • Du kan inte räkna med att de som granskar ditt projekt är bekanta med det klassbibliotek du använder. I implementationsbeskrivningen i projektrapporten behöver du därför vara extra noggrann med att beskriva klassbiblioteken och hur de används i ditt projekt, och du kan behöva fler sidor än det angivna antalet. Missar du det kan du få tillbaka projektet för komplettering av dokumentationen.

  • Klassbiblioteken laddas normalt ner som JAR-filer (arkiv), och ska också alltid läggas till som JAR-filer i IDEA-projektet och checkas in. De ska inte ligga med som källkod eftersom de då kommer att analyseras som om de vore en del av din egen kod! Du behöver lägga till dem i IDEA även om du till vardags använder en annan utvecklingsmiljö, så att kodanalysen fungerar korrekt och handledarna kan testköra i IDEA.

  • Den kod du själv skriver måste så klart fortfarande ha en rimlig omfattning (bredd och djup). Klassbibliotek kan eventuellt hjälpa dig att komma längre men gör inte att du kan minimera den egna kodens omfattning.

Användande av okompilerad källkod från andra

• Du får (i måttlig grad) använda enskilda fullständiga klasser vars källkod du hittar på nätet, under förutsättning att du markerar dem med annoteringen @BorrowedCode enligt nedan.

• Du får (i måttlig grad) använda enskilda kodfragment som du hittar på nätet. Om kodfragmenten är längre än 1-2 raded ska de göras till separata metoder som markeras med @BorrowedCode enligt nedan. Är kodfragmenten mycket korta och svåra att lägga som egna metoder räcker det att istället använda en kommentar som innehåller texten "borrowedcode" (exakt så!).

• Du får givetvis lära dig och inspireras av enskilda enklare kodrader du hittar på nätet, och om du faktiskt har lärt dig tillräckligt för att skriva detta själv utan att "titta på facit", får du använda sådan egenskriven kod utan att ange en källa. Men om det handlar om enstaka rader som du inte anser att du helt och fullt kan skriva på egen hand, är det bättre att ta det säkra före det osäkra och ange källan!

• Motsvarande gäller även kod från tjänster som ChatGPT, GitHub Copilot och liknande. Ett citat från TDDE23: "Alltså, om ni lämnar in programkod och försöker få det att framstå som att ni har skrivit den själv, medan ni i själva verket har fått den från en AI-tjänst eller hittat den på gatan, då är det fusk." Samtidigt kan man använda dessa verktyg för att lära sig så att man sedan kan skriva kod på egen hand.

  I projektet kan man också i måttlig grad använda kod som skrivits av dessa tjänster så länge som det markeras tydligt. (I labbarna är detta mer tveksamt, eftersom det då handlar om specifika uppgifter där man ska kunna skriva koden på egen hand.)

För att markera lånad kod (klasser, metoder och fältdefinitioner) används alltså annoteringen @BorrowedCode, som är specifik för den här kursen och följer med i tddd78-annotations.jar i det projekt du får i Gitlab. Exempel på användningen finns i src/se/liu/tddd78/examples/HowToBorrowCode.java i ditt projekt.

Det är viktigt att du anger en källa med source-attributet. Källan kan t.ex. vara en länk till Stack Overflow eller liknande. Attributet har inget speciellt format, så du kan t.ex. säga:

Samarbete med andra kursdeltagare

• Inom en projektgrupp samarbetar man naturligtvis.

• Det är fullt tillåtet att diskutera gemensamma lösningar på ett problem med personer i en annan grupp, t.ex. hur man strukturerar en del av koden, så länge som varje projektgrupp skriver sin egen kod.

• Om man faktiskt skriver koden tillsammans med personer i en annan grupp, eller skriver av, räknas detta som lånad kod enligt ovan och måste markeras enligt instruktionerna!

Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2024-02-04