Labbar

Här hittar ni kursens labbar.

Labb 1 Ingen som har fått en labbuppgift godkänd av Kattis har fått den underkänd av mig under den manuella rättningen. Däremot har jag följande allmänna kommentarer om er kod:
- Några av er klistrar in Kattio.java med er egen kod. Försök i möjligaste mån att skicka in flera separata filer istället. Jag vet att några av er har haft svårt att få det att fungera hemifrån. Om ni inte får det att fungera efter att ha läst Kattis manual, så lägg ingen tid på saken.
- Flera av er gjorde onödigt krångliga lösningar av Indexmapping. Den kan lösas närmast direkt med C++ klass "map". De som gjorde en egen lösning bör alltså ta en titt på "map".
- Globala variabler är ett enkelt fulhack som fungerar bra när man löser uppgifter på hemtal och problemsessioner. Det är dock mycket olämpligt att använda globala variabler i bibliotekskod. Undvik alltså sådana i resterande labbar (dvs ni riskerar att bli underkända om det förekommer omotiverade globala variabler i er kod).
- Använd C++ templates och Java generics i större utsträckning än vad ni gör. Om ni är osäkra på hur dessa fungerar rekommenderar jag att först skriva en version som fungerar för tex strängar och sedan "templatisera".
Labb 2
Labb 3
Labb 4

Upplägg

Kursen innehåller fyra labbar, som är en del av problemlösningsmomentet i kursen. Varje labb innehåller ett antal labbuppgifter. Målet med labbarna är att ni ska utveckla ett återanvändbart kodbibliotek med implementationer av användbara algoritmer och datastrukturer. Labbarna är inte obligatoriska, men det finns två goda skäl att göra dem ändå; dels ger de betygspoäng (se examination), dels kommer ni att ha möjlighet att använda det ni gjort på labbarna under problemlösningssessionerna och även för att lösa hemtalen.

Bedömning av labbar

Bedömningen av inlämnade labbar består av två delar:

Ett automatiskt test som genomförs av domarsystemet Kattis. För varje labbuppgift finns en motsvarande uppgift hos Kattis som låter henne verifiera att ni har löst labbuppgiften korrekt.
En subjektiv bedöming av kvaliteten på er kod. Den består i att vi läser koden och kontrollerar att den är väl dokumenterad och strukturerad (se vidare Krav på koden nedan).

Inlämning

En labbupgift anses inlämnad om motsvarande Kattis-uppgift är löst vid deadline för labben. Vid granskningen kommer vi att titta på den senaste godkända inskickningen som inkom innan deadline. Tänk på att det är den koden som kommer att granskas (och som därför ska vara bra kommenterad).

Obs! Varje person i labbgruppen måste själv skicka in en lösning på Kattis-uppgiften för att lösningen skall registreras för honom/henne.

Deadlines

Deadlines anges i labblydelserna.

Krav på koden

Allmänna krav

Koden ska vara kommenterad och snyggt strukturerad. Till varje uppgift ger vi förslag på vad funktionen/klassen som ska implementeras kan ta för parametrar och vad den kan returnera. Detta är dock inte något som ni behöver följa slaviskt, om ni tycker att det blir snyggare att göra på något annat sätt går det bra, så länge funktionen fortfarande löser uppgiften som ska lösas. Läs gärna GNU coding standards och/eller Google coding standards för inspiration, men använd ert sunda förnuft.

Författare

Författarens (eller författarnas, om det är en grupp) namn ska finnas som en kommentar högst upp i koden.

Dokumentation

Alla funktioners och klassers funktionalitet ska vara dokumenterad med kommentarer i koden.

Felhantering

Idealiskt vore förstås om era algoritmer och datastrukturer var helt robusta och generella, men det kan vara svårt. Exceptionella fall måste hanteras på något sätt, t.ex. genom att kasta undantag eller åtminstone genom att ni dokumenterar dem.

Mer detaljerade krav

Här följer tolkningar, tillämpningar och tumregler som har med kraven att göra. Det är inte en uttömmande lista på vad som behövs.

Separera funktionaliteten från inläsningen. Läs indata skicka till "lösaren" och ta emot utdata. Låt inte den "generella" algoritmen vara ansvarig för läsning och skrivning. Algoritmen ska inte vara specialsydd för Kattistesterna.
Se till att dela upp koden i flera filer. Klistra inte ihop Kattio.java med er egen kod!
För mycket insprängda kommentarer. Ofta är enstaka rader någorlunda självdokumenterande och kommentarer av typ
// läser indata till buffert
är nästan alltid onödiga. Kommentera inte enstaka rader utan skriv kommenterarer som förklarar hela metoder eller större kodblock inom en metod.
Kommentera API för centrala funktioner så man vet vad in- och utparametrar/returvärden är. Kommentera i första hand för den som ska anropa koden, inte för den som ev ska ändra i koden.
Labbuppgiften anger förslag till ett API. Använd det om ni inte hittar något som är lika bra eller bättre (med avseende på återanvändbarhet). API:t ska inte vara specialsytt för de tester som körs på Kattis.
Author(s) överst i alla filer, även headerfiler och tidiga inskickningar.
Alla i gruppen ska skicka in!