Granskning
- Inlämningsdatum 29 jan 2023 av 18:00
- Poäng 0
- Lämnar in en filuppladdning
| När du lämnar in för granskning |
Här lämnar du in din P-uppgift för granskning. Om du har flera programfiler - slå ihop dom till en så blir det enklare för din granskare. Vi parar ihop dig med en granskare när du lämnat in - du behöver inte själv hitta en granskare. |
|
När du granskar en annans uppgift |
Innan du börjar granska - läs först denna beskrivning av granskningsprotokollets delar. När du genomför granskningen:
|
Matris
Hitta matris
Inkludera en titel
Kom ihåg att 48 studenter redan har bedömts med den här matrisen. Om du ändrar den påverkas deras bedömningar.
| Kriterier | Bedömningar |
|---|---|
|
Informativa utskrifter
Programmet ska tala om för användaren vad programmet gör i varje steg och vilken inmatning som förväntas.
|
|
|
Enkel inmatning
Inmatningen ska inte vara onödigt krånglig.
|
|
|
Vettiga namn
Programmet ska ha intuitiva namn på variablerna.
|
|
|
Kommentarer
Alla klasser och funktioner måste kommenteras. Syftet med klassen/funktionen ska framgå. Det ska räcka att läsa kommentaren för att förstå hur en funktion ska användas (man ska inte behöva sätta sig in i hela koden).
In- och utdata till funktioner måste kommenteras. Det gäller både returvärden och parametrar. Om funktionen är en metod och den ändrar något attribut ska detta också kommenteras. |
|
|
Konsekvent språk
Språkvalet ska vara konsekvent. Alla variabel-, klass- och funktionsnamn på ett språk. Alla kommentarer på ett språk. Det är OK att ha engelska variabel/metodnamn och kommentera på svenska.
|
|
|
Konsekvent typografi
Programmet ska ha en genomgående typografi. Namn som är sammansatta av flera ord kan t ex skrivas ihop genom att inleda varje nytt ord med stor bokstav (t ex summeraVikter), eller genom att skilja orden åt med understreck (t ex summera_vikter), men använd samma variant genom hela ditt program.
Variabel- och metodnamn brukar inledas med med liten bokstav (t ex antal = 0) och klasser med stor bokstav (t ex class Cykel). |
|
|
Felhantering
Extrauppgiften för betyg C innehåller oftast felhantering, dvs att programmet kan hantera fel som kan uppstå under körning. Oftast gäller detta användarens inmatning, men för vissa uppgifter kan det handla om att upptäcka fel i indatafiler. Se uppgiftslydelsen!
|
|
|
Lämplig uppdelning i funktioner
Varje funktion ska ha en väl avgränsad uppgift. En tumregel är att ingen funktion ska vara längre än en skärmsida.
|
|
|
Lämplig uppdelning i klasser/moduler
Data som hör ihop (t ex namn, födelsedata och adressuppgifter för en person) kan samlas genom att dom får vara attribut i en klass. Funktioner som hör ihop med dessa data får bli klassens metoder. Ett program kan ha flera olika klasser.
Ett riktigt stort program kan delas upp i flera moduler, där de klasser som hör ihop samlas i en modul. |
|
|
Temporära variabler så lokalt som möjligt
Se till att tillfälliga variabler skapas så lokalt som möjligt. Exempel: En variabel som bara används inuti en slinga i en metod ska inte vara ett attribut i klassen, utan en lokal variabel i metoden.
|
|
|
Återanvändbara funktioner/moduler/klasser
En del uppgifter kan delas upp i klasser som går att återanvända i andra program. T ex kan en klass som representerar ett spelkort användas i olika kortspelsprogram.
Funktioner ska om möjligt vara skrivna så att dom går att använda i andra sammanhang. Ett knep är att se till att alla indata ges som parametrar. Ett annat är att specialisera funktionerna, så att varje funktion bara gör en liten del. |
|
|
In- och utdata till funktioner
Var noga med in och utdata till funktionerna. En del funktioner som t.ex. bara skriver ut på skärmen kan vara parameterlösa och inte returnera något. Övriga funktioner bör ha alla indata som parametrar och utdata som returvärden.
|
|
|
Flexibelt/utbyggbart program
Skriv ditt program så att det lätt att utöka och bygga ut. Några exempel: I ett program som samlar data om pokemon ska man kunna lägga till fler pokemon utan att gå in och ändra i programmet. Om ett program läser in från fil ska det vara lätt att byta till en annan fil. Om man vill lägga till en beräkning så ska det vara enkelt att stoppa in en funktion för det, utan att behöva ändra på många ställen i programmet.
|
|
|
Ingen kodupprepning
Om ett nästan identiskt kodstycke förekommer på flera ställen i programmen bör den upprepade koden skrivas om till en funktion med parametrar och ev returvärde.
|
|
|
Ingen hårdkodning
Förekommer ett tal (t ex 8) på flera ställen i programmet? Då är det bättre att definiera den som en konstant, t ex RADER = 8.
|
|
|
Uppfyller kraven i lydelsen
Gå igenom uppgiftslydelsen och jämför med programmet. Kontrollera att allt är klart!
|
|
|
Detaljförståelse
Kan den som skrivit programmet förklara allt i detalj?
|
