Labbar

Här hittar ni kursens labbar.

• Labb 1
• 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, 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.

Varje labb kan ge upp till 9 betygspoäng på moment LAB1. Labbarna kan göras i grupper om upp till två personer. Labbar lösta efter deadline ger inga poäng alls.

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 ni presenterar er kod för oss och visar att den är väl dokumenterad och strukturerad (se vidare Krav på koden nedan).

Redovisning

Ni redovisar era lösningar muntligt, ca 10 minuter per grupp. I samband med labb-deadline skickas en bokningslista ut per mail för att boka tid för redovisning.

Inom en dag efter deadline (eller innan, om ni känner er klara innan) ska varje grupp skicka ett mail till popuph-14@csc.kth.se som innehåller följande:

• Subject/ärende: "[popuph14] Labb X", där X är ordningstalet på labben.
• Lista över vilka (upp till två personer) som ingår i gruppen.
• En lista över vilka problem som lösts samt länk till Kattis-inskickning för varje problem.

Deadlines

Deadline för varje labb är kvällen innan respektive problemsession. Se schemat för exakta datum och tider.

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.

1. Koden ska vara generell och inte ha konstanter hårdkodade till storleksgränserna i Kattis-problemet -- om storleksgränserna i Kattis-problemet ökas ska er lösning klara av det (inom rimliga gränser -- det är OK att göra antaganden om t.ex. hur stor heltalsdatatyp som behövs för att representera svaret, men INTE OK att att t.ex. anta att en sträng är högst 5000 tecken lång bara för att den råkar vara det i Kattis-problemet).
2. 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 sådana.
3. 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.
4. Se till att dela upp koden i flera filer. Klistra inte ihop Kattio.java med er egen kod!
5. 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.
6. 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.
7. 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.
8. Author(s) överst i alla filer, även headerfiler och tidiga inskickningar.