• Betyg 3/G: Ange alltid ett paket för din kod.

• Betyg 4/VG/5: Dela upp projektet i lämpliga delpaket. Om det inte går att hitta lämpliga grupperingar kan det hända att projektet inte har tillräcklig omfattning, att för mycket kod ligger i en och samma klass, eller att projektstrukturen behöver justeras. Det kan också hända att projektet verkligen inte lämpar sig för uppdelning, men det är ovanligt.

• Betyg 3/G/4/VG/5: Ta bort död kod, det vill säga kod som aldrig kan anropas och därmed inte kan testas eller demonstreras ordentligt.

  Ta också bort bortkommenterad kod.

  (I Git kan ni fortfarande komma åt den borttagna oanvända koden om ni vill fortsätta med den senare. Det går också att skapa en egen gren (branch) just för borttagningen inför inlämningen, och byta tillbaka till huvudgrenen (master) för vidareutveckling.)

Genom att abstrahera, parameterisera och generalisera kan man på kortare tid skriva kortare, mer lättläst och mer utökningsbar kod utan onödiga upprepningar. Detta är alltså viktigt av många anledningar.

• Betyg 3/G: Upprepad / repetitiv kod accepteras i små mängder. Alltför repetitiv och ineffektiv kod ger ofta komplettering, även när det inte gäller "exakt" upprepning. Gå genom all din kod och undersök om det finns något du tycker borde kunna uttryckas effektivare, kod där det känns som om du inte borde ha behövt skriva så mycket som du gjorde. Antagligen behövde du inte det!

• Betyg 4/VG/5: Upprepad / repetitiv kod bedöms hårdare.

Detta är en vanlig källa till komplettering eller betygssänkning!

• Betyg 3/G: Projektbeskrivningens implementationsavsnitt måste ge en bra översikt över programmet, typiskt på 3–6 sidor (givet att det mesta är text). Detta är en del av examinationen som delvis ersätter en tenta.

  Koden måste också vara tillräckligt lättförståelig. Första steget är alltid att skriva självförklarande kod, men oftast krävs också en del kommentarer, både när det gäller varför man gör något och hur man gör det.

  Med detta sagt vill vi också säga att vi har sett extremt stora variationer i hur man kommenterar sina projekt. Vissa kommenterar alldeles för lite, medan andra ligger mycket över våra krav. Meningen är inte att varje fält, metod och kodstycke ska ha den perfekta och fullständiga beskrivningen, utan man behöver arbeta tillräckligt med kommentarerna för att den som läser koden ska få tillräckligt med information så man klart och tydligt förstår vad som händer och varför.

• Betyg 4/VG/5: Varje klass ska kommenteras med en övergripande Javadoc-kommentar som beskriver klassen (syfte, användning, relation till andra klasser, ...). Kommentarerna ska vara tillräckligt informativa för att man ska kunna få en rimlig förståelse för klasserna helt utan att läsa någon programkod! Javadoc-formatet beskrivs i en kursbok du har valt, eller t.ex. i Oracles egen dokumentation. Självklart kan även andra kommentarer behövas.

  Dessutom ska alla eventuella publika fält Javadoc-dokumenteras ordentligt. (Sådana fält ska normalt undvikas.)

• Betyg 3/G/4/VG/5: Undvik globala variabler (icke-konstanta static-fält) och Singleton-mönstret. I undantagsfall kan detta vara den bästa lösningen, men det är mycket vanligare att det leder till komplettering.

När man läser in resurser via t.ex. ClassLoader.getSystemResource() kan det hända att de saknas. Man får då null tillbaka, vilket kan leda till NullPointerException senare i koden.

Detta behöver inte hanteras, eftersom det i så fall beror på felaktiga resursnamn eller problem med själva installationen av programmet. Det är att jämföra med att klassfiler saknas i installationen, vilket vi inte heller har separat felhantering för.

Med "upptäckta fel" menar vi dels undantag (exceptions) som fångas efter att de uppstår i egen kod eller andras kodbibliotek, dels andra typer av fel som man upptäcker på andra sätt, t.ex. genom att man själv kontrollerar om användaren ger felaktig input eller om en metod signalerar fel genom att returnera null.

• Betyg 3/G: Upptäckta fel får inte bara ignoreras.

  Om ett fel beror på användarens input, t.ex. att användaren har matat in felaktig information i en dialogruta, valt en fil som inte kan öppnas eller har styrt en spelare utanför skärmen, ska det hanteras genom att användaren får en ny chans att ge korrekt input.

  I övriga fall är det önskvärt att fel hanteras korrekt enligt kraven för betyg 4 nedan, men acceptabelt (för betyg 3/G) att helt enkelt skriva ut en stacktrace och avsluta programmet. Då demonstrerar du att du vet var felen kan uppstå och var de borde hanteras, och undviker många farliga följdfel.

  Att ignorera fel och fortsätta är inte acceptabelt för betyg 3/G.

• Betyg 4/VG: Upptäckta fel ska hanteras korrekt. Detta innebär bland annat att fel ska hanteras på rätt plats, att man inte får "fånga och ignorera / glömma bort" felen, att man ska tänka på potentiella följdfel (om jag fångar felet här och fortsätter, vad händer då?), och att man vid behov ska ge rimliga felmeddelanden till användaren. Läs vidare i de specifika tipsen!

  Om det är helt orimligt att programmet ska kunna fortsätta köra efter felet, är det acceptabelt att helt enkelt skriva ut en stacktrace och avsluta programmet. I övrigt ska fel hanteras enligt bästa förmåga.

• Betyg 5: Exceptions som fångas ska dessutom loggas med hjälp av Javas loggningssystem (java.util.logging), tillsammans med rimliga felmeddelanden.

• Betyg 3/G: Projektets filer får läsas in via vanlig filhantering. Detta gäller alltså filer som finns med projektet från början, t.ex. bilder och spelbanor.

• Betyg 4, VG, 5: Javas stöd för resurser ska användas om du behöver läsa in filer (bilder, ljud, banor, inställningar osv.) som tillhör och "levereras med" programmet. Använd alltså ClassLoader.getSystemResource(). På det sättet undviker vi att behöva ange var filerna finns i en specifik installation, och filerna kan hämtas även om hela programmet råkar vara packat i en JAR-fil (liknande ZIP-fil). Om du även skriver till en fil behöver du inte använda resurser för den filen, eftersom du i så fall ändå måste veta var filen är placerad.

För klassbibliotek i kompilerat format gäller följande:

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

• Du får också använda MigLayout och GSON, som vi har refererat till under föreläsningar och/eller i labbarna. Du måste då lägga till själva JAR-filerna i det incheckade projektet och lägga till dem som libraries i IDEA-projektet. 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.

  När du lämnar in detta projekt kan du alltså inte använda verktyg som Maven eller Gradle för att automatiskt hantera beroenden. Verktygen är visserligen bra, men sätter käppar i hjulen för vår kodinspektion.

• Du får gärna använda andra fullständiga klassbibliotek som du laddar ner från nätet, under följande förutsättningar:

  • Klassbiblioteken får inte vara ramverk som "tar över" projektet. Det måste vara din kod 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.

  • Du kan inte räkna med att de som granskar ditt projekt är bekanta med det klassbibliotek du använder. I implementationsbeskrivningen i projektmallen behöver du därför vara extra noggrann med att beskriva ramverken och dess användning 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 ska läggas till som JAR-filer i projektet och checkas in. De ska inte ligga med som källkod (se nästa punkt).

• Du får använda enskilda fullständiga klasser vars källkod du hittar på nätet, under förutsättning att du lägger dem i ett paket vars namn innehåller "borrowedcode" (exakt så) eller lägger till "BorrowedCode" i klassnamnet. Du kan t.ex. lägga dem i package se.liu.liuid123.game.graphics.borrowedcode om ditt LiU-ID är liuid123, eller döpa en klass till MyListenerBorrowedCode. Detta mönster används sedan i automatisk kodanalys!

  Regeln gäller även om du modifierar den kod du hittar.

• Du får använda enskilda kodfragment som du hittar på nätet. Om kodfragmenten är längre än 2-3 rader ska de göras till separata metoder vars namn innehåller "borrowedcode", t.ex. "borrowedcode_dijkstras_algorithm()". Detta mönster används sedan i automatisk kodanalys! Är kodfragmenten högst 3 rader kan det räcka med en kommentar som innehåller texten "borrowedcode".

  Regeln gäller även om du modifierar den kod du hittar.

• Du får givetvis inspireras av enskilda enklare kodrader du hittar på nätet, och om du anser att 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 inspirationen.

För samarbete med andra grupper gäller följande:

• Det är fullt tillåtet att diskutera gemensamma lösningar på ett problem, 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, och sedan utgår från en gemensam fil, räknas detta som lånad kod enligt ovan!