7. P-uppgift: kodskelett
Programmeringsteknik
Innehåll |
P-uppgift
Kursens sista moment är en större, personlig programmeringsuppgift i Python; en P-uppgift. Uppgifterna är tänkta att vara något så när svåra och tidskrävande, räkna med cirka 60 timmar. Betyget i kursen ges av detta moment.
P-uppgiften redovisas i fyra steg, kodskelett, prototyp, granskning och slutredovisning (se nedan). Du måste boka en tid för slutredovisningen.
Uppgiftslydelsen till din uppgift får du med e-post så snart du är klar med de tre första inlämningsuppgifterna.
P-uppgiftens delmoment
Kodskelett
Innan programmet skrivs ska en specifikation i form av ett kodskelett lämnas in. Syftet är att du ska tänka igenom problemet innan du försöker lösa det. Kodskelettet ska innehålla följande delar:
- En inledande kommentar som kortfattat beskriver vad programmet gör och hur det är implementerat.
- Funktioner (utan kod) med kommentarer.
- Klasser med attribut och metoder (om du använder klasser), men utan kod.
Granskning
Innan det färdiga programmet kan redovisas för en handledare på KTH ska det testas (granskas) av en kurskamrat. Vid testen ska din granskare kritiskt granska ditt program, testköra det och fylla i ett granskningsprotokoll. Denna granskning är ett obligatoriskt moment. (Varje kursdeltagare måste granska en uppgift, och alla uppgifter som ska redovisas för handledare måste granskas först.) Syftet med granskningen är att du genom att kritiskt granska en annans program ska få en ökad förståelse för hur man ska (och inte ska) programmera.
Slutredovisning
Du väljer (normalt via webben) en tid för slutredovisning. Uppgiftslydelsen, en utskrift av programmet samt granskningsprotokollet ska medföras till slutredovisningen. Observera att vi (för att förhindra fusk) jämför din lösning mot tidigare lösningar.
Krav på P-uppgiftslösningen
Utöver kraven på funktionalitet som finns i uppgiftslydelsen gäller detta alltid:
- Programmet ska vara kommenterat upptill med författare, datum och ev revisionsdatum. Överkommentera inte programmet i övrigt. Tänk på att det är kvalitet och inte kvantitet på kommentarer som räknas.
- Programmet ska vara användarvänligt och presentera sig vid programstart. Tydliga instruktioner ska ges på skärmen. Det ska vara lätt att förstå vad programmet skriver ut. Det är tillåtet att anta att indatafiler är felfria om inte annat anges i uppgiftslydelsen.
- Programmet ska vara vettigt uppdelat i funktioner, och eventuellt klasser. Funktioner ska inte vara alltför långa (max en skärmsida). Det ska vara lätt att i efterhand gå in och förstå och ändra i programmet. Robust, flexibelt och lättläst är nyckelord.
- Varje variabel och funktion ska vara försedd med kommentarer. Ange vad variabeln representerar och vad funktionen gör. För funktioner bör man också ange vad indata (parametrar) och utdata (retur-värde) betyder. Det ska räcka att läsa kommentar och funktionshuvud för att förstå hur en funktion ska användas.
- Namn på variabler och funktioner ska vara vettiga. Alla deklarerade namn ska vara på samma språk, liksom alla kommentarer (engelska namn och svenska kommentarer är OK). Koden skall vara snyggt formaterad.
- Nästan identiska kodstycken ska inte upprepas. Gör i stället generella funktioner. Inför inte i onödan begränsningar. Inför konstanter för sådant som man kan tänkas vilja ändra framöver (om man skulle vilja arbeta vidare med din lösning) och för tal som inte ska ändras och går att beskriva med namn.
Inlämningsuppgift 4
TODO
