Föreläsningar

Här samlas kursens föreläsningar. Inspelningar från den här kursomgången läggs till allteftersom de hålls; fram tills dess finns föregående kursomgångs inspelningar nedan.

Läs innan föreläsningen

Läs enligt läsanvisningarna innan respektive föreläsning – då blir det lättare att delta aktivt, ställa frågor och diskutera, och du får mer utbyte av föreläsningen.

Kursintroduktion

Kursintroduktion

Introduktion till mjukvarukvalitet

Video

2026-09-01 0:18:08

Sammanfattning

Kursledning

Kursen (1DV610) leds av Mats Lock och Daniel Toll, båda universitetsadjunkter vid Institutionen för datavetenskap och medieteknik. Det är Daniel Tolls första omgång av just den här kursen, medan Mats redan är van vid upplägget — Daniel håller själv i stora delar av introduktionen och skämtar om att han “inte kan någonting om det här än”.

Kalmar och distans

Kursen ges i två parallella kurstillfällen: Kalmar (campus, svenska) och distans (Webbprogrammerare online, svenska). Du ska delta i det kurstillfälle du är registrerad på, om inte annat är överenskommet med kursledningen i förväg.

Kommunikation

• Kurswebben — föreläsningar och material publiceras löpande under kursens gång; en del äldre material kan ännu ligga under revidering.
• Zulip ersätter Slack som kursens huvudsakliga kommunikationskanal. Slack fasas ut eftersom universitetets kostnad för tjänsten fördubblades när driften flyttade från USA till Europa, vilket tvingade fram en övergång till en gratisnivå som inte behåller meddelandehistorik. Håll uppsikt i Zulip, använd öppna kanaler för allmänna frågor och direktmeddelanden för personliga ärenden.
• Zoom används för föreläsningar (som spelas in) och för distansstudenternas workshoppar.
• Kursledningen (Mats och Daniel) kommunicerar sinsemellan via Teams, men det är inte en kanal du förväntas använda.

Kursens innehåll

Föreläsningarna är relativt få till antalet och fungerar som en bas att stå på snarare än att täcka allt själva — tanken är att du läser det aktuella kapitlet i kurslitteraturen innan varje föreläsning, så blir föreläsningen en repetition och diskussion av det du just läst. Kursboken är dock inte heltäckande: en del av innehållet på tentamen kommer enbart från föreläsningarna.

Examinationen består av tre laborationer, tre workshoppar och en tentamen. Deadlines finns i schemat, och nya uppgifter publiceras löpande under kursens gång — prata med kursledningen i förväg om du vill arbeta i förväg med material som ännu inte är helt reviderat.

Betygsformel

Laboration 1, Workshop 1, Workshop 2 och Workshop 3 är boolska moment (godkänd/underkänd) — samtliga måste vara godkända för att ett slutbetyg alls ska kunna sättas. Laboration 2 och Laboration 3 viktas därefter 50/50 och utgör tillsammans 60 % av slutbetyget; tentamen utgör de resterande 40 %.

Den muntliga tentamen och Laboration 3:s slutredovisning sker vid samma tillfälle, under kursens två sista veckor.

Akademisk integritet

• Kopiera inte andras kod eller reflektioner och utge dem för dina egna — men det är fullt tillåtet att använda andras kod (till exempel ett bibliotek, eller en modul med öppen källkod) så länge den delen tydligt är markerad som inte din egen.
• Du förväntas äga ditt eget användande av AI. Kursen har tidigare varit betydligt mer restriktiv kring AI-verktyg; den här omgången låser upp ett friare användande, med fokus på att AI ska stödja ditt lärande — inte lösa uppgiften åt dig. Kursledningen är inte primärt intresserad av den färdiga produkten du lämnar in, utan av hur ditt eget tänkande och din förståelse har utvecklats, vilket är själva anledningen till att en muntlig tentamen avslutar kursen.
• Gör regelbundna commits och pusha regelbundet — kursledningen ska kunna följa din arbetsinsats över tid. Ett projekt som lämnas in med en enda commit (eller ett fåtal) tolkas som att lösningen har genererats vid ett enda tillfälle snarare än vuxit fram successivt, och riskerar att inte bedömas alls. Använder du AI för att skriva kod förväntas det ske stegvis, inte som ett enda “one-shot”-anrop du sedan klistrar in — annars lär du dig ingenting av processen, även om du läser igenom den färdiga lösningen efteråt.
• Om din livssituation gör att du känner dig pressad att fuska: hör av dig till kursledningen istället. Ni kan tillsammans lägga upp en plan (vid behov tillsammans med studieadministrationen) så att du klarar både studierna och livet i övrigt.

Kurslitteratur

Boken Clean Code av Robert C. Martin finns i två utgåvor du kan använda:

• Gamla utgåvan — ISBN-13 9780132350884, Prentice Hall, ca 464 sidor.
• Nya, andra utgåvan — ISBN-13 9780135398579, Addison-Wesley Professional, utgiven 2025, 672 sidor.

Den nya utgåvan är omarbetad och moderniserad (2008 → 2025) snarare än utökad i omfång — även om sidantalet skiljer sig, är ambitionen densamma.

Veckans laboration

Laboration 1 förväntas du påbörja redan denna vecka; den lämnas in senast torsdag. Den ligger på en medvetet låg nivå — huvudsyftet är att komma tillbaka i programmerarrollen, känna dig hemma i din utvecklingsmiljö och dina verktyg, och kunna committa och pusha kod. Passa gärna på att experimentera med AI-verktyg om du inte har jobbat så mycket med dem tidigare.

Föreläsning 1: Meningsfulla namn

Läsanvisningar inför föreläsning 1

Färgförklaring för chipsen nedan:

• Läs
• Skumma
• Hoppa över

Clean Code

• Ch. 1
• Ch. 2

Clean Code, 2nd Edition

• Ch. 1
• Ch. 2
• Ch. 3
• Ch. 4

Föreläsning

Namn med mening

Video

2026-09-01 1:33:16

Sammanfattning

Kod körs på datorer, läses av människor och AI

En dator försöker aldrig förstå koden — den kör den. Källkod kompileras, JIT-kompileras eller interpreteras till instruktioner som exekveras rakt av mot en tillståndsmodell (alla variabler, databaser och filer ett program håller reda på tillsammans utgör dess tillstånd). Koden måste följa en strikt syntax (annars blir det ett syntaxfel), men datorn bryr sig inte det minsta om namngivning, formatering eller vilket språk du väljer på dina identifierare — bara att du använder samma ord konsekvent. Historiskt använde man ibland en obfuskerare för att korta ner identifierare (kortare namn = mindre data att skicka från server till klient); idag spelar det knappt någon roll för överföringen, men principen — att datorn själv inte bryr sig om namn — kvarstår.

Människor (och numera AI) läser koden av ett helt annat skäl: för att tolka den och bygga en intern mental modell av vad den gör, varför och hur den hänger ihop med andra delar av systemet — inte bara koden själv, utan även andra artefakter som krav, commit-historik och diagram. Vi har svårt att hålla mer än ungefär fem till nio saker i huvudet samtidigt, så ju bättre kod och andra artefakter är strukturerade och abstraherade, desto lättare blir den mentala modellen att bygga — och desto färre feltolkningar gör vi.

En refererad (inte närmare citerad) undersökning ska ha visat att AI kan underhålla “clean code”-skriven kod omkring 30 % effektivare — samma princip som gäller för mänsklig läsbarhet verkar alltså gälla lika mycket för AI.

Abstraktion

Ett BankAccount-objekt med metoderna deposit() och withdraw() är ett exempel på abstraktion: all komplexitet kring databaser, säkerhet och inloggning bakom ett bankkonto är gömd bakom ett enkelt interface. Vi behöver varken veta eller bry oss om vilken typ av databas som ligger bakom — vi ser bara den avskalade bilden av det hela. Det är själva poängen med objektorientering: informationsgömning (information hiding) gör att andra utvecklare (eller AI) inte behöver känna till implementationsdetaljerna för att kunna använda ett objekt korrekt.

Readability och understandability

Föreläsningens två huvudbegrepp, medvetet kvar på engelska eftersom det är de termer boken använder:

• Readability (läsbarhet) — hur lätt det är att läsa en text, det vill säga gå från symboler på en skärm till ord i huvudet. Handlar om sådant som ordlängd, radlängd, mellanslag, indenteringsstil, typsnitt och färgkodning.
• Understandability (begriplighet/kodförståelse) — förmågan att återskapa den ursprungliga programmerarens avsikt, att rekonstruera den bakomliggande mentala modellen. Att läsa något är inte samma sak som att förstå det.

De två samspelar inte alltid: camelCase ger långa namn som är sämre för läsbarheten men bättre för begripligheten, medan väldigt korta namn (x i stället för windowPositionX) är lättlästa men säger inget om avsikten. Långa “wall of text”-kommentarer är ett annat exempel — bra för begriplighet, dåligt för läsbarhet, eftersom de flesta helt enkelt inte orkar läsa dem.

Ett återkommande exempel genom föreläsningen: talet 1492. Med hjälp av readability läser vi fram siffrorna (om vi inte råkar läsa fel tecken, t.ex. l/1-förväxling), men den korrekta tolkningen (understandability) beror helt på sammanhanget — är det ett årtal kopplat till Columbus expedition, ett highscore i ett tv-spel, eller något helt tredje? Förståelser är kontextuella: ju tydligare kontext, desto lättare att landa i rätt tolkning.

Vad som påverkar readability

• Ord- och radlängd — kortare är i allmänhet bättre (x är snabbare att läsa än windowPositionX), men hjärnans mönsterigenkänning gör att välbekanta långa namn ändå blir lätta att känna igen med träning.
• Mellanslag, tabbar, klammerparenteser och indenteringsstil.
• Redigerare, verktyg och personliga preferenser (t.ex. vana vid syntax-färgkodning — obefintligt förr, standard idag).
• Typsnitt, färger, radbrytningar.

Readability handlar bara om att föra över information från skärm till mentala ord — inte om att tolka vad ordet faktiskt betyder.

Vad som påverkar understandability

• Namn på identifierare (klasser, variabler, metoder).
• Kommentarer — bra för begriplighet, men kan skada läsbarheten om de blir för långa.
• Klassdesign, beroenden, arkitektur och specifika termer/domänbegrepp.
• Individuellt språkbruk och individuell kompetens — olika personer (eller AI-modeller) bygger olika interna modeller utifrån samma ord, beroende på egen bakgrund och kontext (ett exempel: finalPrice kan betyda olika saker i en webbutik jämfört med ett spel).
• Andra artefakter än själva källkoden: commit-historik lyftes som ett konkret exempel — tydliga, AI-genererade commit-meddelanden och en ren branch-historik ger idag ett mycket rikare underlag för att förstå hur ett projekt har vuxit fram, jämfört med tidigare års kortfattade handskrivna commit-texter.
• Inkonsekvent namngivning och stavning.

Ett återkommande resonemang: när vi löser ett problem uppstår ofta en streckad, outtalad koppling mellan två delar av koden (t.ex. en plats som skriver till en databastabell och en annan som läser från samma tabell) som bara går att upptäcka genom att faktiskt läsa båda ställena. Kommer en annan programmerare (eller du själv, en timme eller ett år senare) tillbaka till koden utan den ursprungliga tankegången i huvudet, är den kopplingen lätt att missa helt.

Övning: en obfuskerad primtalsfunktion

Som demonstration visades en fungerande men medvetet obfuskerad kod som räknar ut primtal mellan 1 och 100 — meningslösa klass-/variabelnamn, inga kommentarer, ett par magiska tal. Poängen var inte att hitta buggen i sig (en student i publiken hittade den snabbt), utan varför koden är svår att förstå trots att den fungerar korrekt för de flesta indata: utan domänkunskap om vad primtal är och utan meningsfulla namn som ger kontext saknas de ledtrådar som annars gör felsökning möjlig.

Ariane 5 var inte ett måttenhetsfel

Under diskussionen om måttenheter som en typ av information som kan gömmas i ett variabelnamn nämndes Ariane 5-raketen som exempel på en katastrof orsakad av att blanda ihop måttenheter (meter/yard). Det var faktiskt en annan rymdfarkost: Mars Climate Orbiter (1999) gick förlorad för att ett team räknade i pound-force-sekunder medan ett annat räknade i newton-sekunder. Ariane 5:s haveri (Flight 501, 1996) berodde istället på ett numeriskt överspill — ett 64-bitars flyttal som konverterades till ett 16-bitars heltal blev för stort, vilket fick styrsystemet att tolka diagnostikdata som riktiga flygdata och göra en kraftig, felaktig kurskorrigering som slet sönder raketen.

Painted types

Painted types (“påmålade typer”) uppstår när ett värde har en särskild betydelse eller särskilda regler, men representeras av en alltför generell typ — en “typ” som bara existerar i utvecklarens huvud, inte i koden. Exempel: ett användarnamn eller lösenord lagras som en vanlig string, en radie som ett vanligt number — inget i typen självt uttrycker att ett användarnamn måste följa ett visst mönster, att ett lösenord har krav på längd och teckentyper, eller att en radie rimligen inte kan vara negativ.

Konsekvensen är ofta duplicerad valideringslogik: samma regler (t.ex. “lösenordet måste vara tillräckligt långt och innehålla tre teckentyper”) kontrolleras på flera ställen i kodbasen, eftersom det bara går att hitta dem genom att läsa igenom koden — inget i typen självt pekar dit. Lösningen, särskilt när kod dupliceras, är att skapa en riktig typ eller klass (t.ex. en Password- eller Radius-klass) som kapslar in både värdet och dess regler på ett ställe.

Meningsfulla namn — regler från Clean Code kapitel 2

• Namn som avslöjar intention — elapsedTimeInDays säger mer än d eller d // elapsed time in days, men avvägningen mellan ett kort namn plus kommentar och ett långt, självförklarande namn beror på hur nära deklaration och användning ligger varandra (korta namn fungerar bra i korta scopes, t.ex. en pilfunktion, eller etablerade konventioner som x/y för koordinater).
• Undvik desinformation — vilseledande förkortningar (hp för hypotenusa, Hewlett-Packard eller Harry Potter?), tecken som liknar varandra (0/O, 1/l/I), inkonsekvent stavning (cycle/cycles/sycle) och inkonsekvent terminologi för samma begrepp.
• Gör meningsfulla skillnader — copyChars(a1, a2) säger inget om vilket argument som är källan och vilket som är målet; copyChars(source, destination) gör det.
• Använd uttalbara namn — recordId går att prata om med kollegor (eller en AI-assistent via röst) på ett sätt pszqint inte gör.
• Använd sökbara namn — magiska tal och alltför korta namn går inte att söka fram; ett namngivet tal (jämfört med en bar magisk siffra) går att hitta i hela kodbasen.
• Undvik encodings — ungersk notation (typ-prefix som bBusy, chInitial), medlemsprefix (m_age, #m_age) och prefix på interface/implementation (IShapeFactory/ShapeFactoryImpl) hör i stort sett hemma i historien nu när moderna redigerare visar typinformation direkt — undantaget är miljöer utan färgkodning eller typinferens, t.ex. inbyggda system som redigeras direkt via en terminal.
• Undvik mental mapping — spara både transformationen och innehållstypen i namnet: lowerCaseUrl istället för bara l (som kräver att läsaren kommer ihåg att “l” betyder en versal-till-gemen-omvandlad URL).
• Klasser är substantiv, funktioner är verb — och funktionsnamn som manipulator/validator (adjektiv-/agentaktiga namn) är ofta en varningssignal att klassen gör för mycket.
• Var inte “cute” — kul referenser (filmnamn, slangnamn på servrar) kan skapa gemenskap inom en liten grupp, men blir ett problem så fort någon utanför den kretsen ska förstå eller underhålla koden och inte fattar referensen.
• Ett ord per koncept, konsekvent terminologi — ett verkligt exempel: samma domänbegrepp bytte namn flera gånger under ett projekts livstid (TestPlan → Document → ReviewItem → DocumentUnderReview); om inte alla instanser byts konsekvent tappar sökning och sammanhang.
• Inga meningslösa utfyllnadsord (“noise”) — nameString eller aName istället för bara name tillför ingen extra betydelse.

Egen forskning om identifierare

En undersökning av cirka 800 000 variabelnamn ur 56 000 slumpvist utvalda Java-projekt på GitHub visade att:

• Omkring 30 % av variablerna bara bär information om sin egen typ (t.ex. View view, String string) — 6,5 % av de primitiva datatyperna och hela 50 % av klassinstanserna (i talarens egen kod närmare 70 %).
• Utöver typinformation lagrar identifierare ofta: roll/relation (child), multiplicitet (names[], pluralböjning), räckvidd (myName/m_-prefix för medlemsvariabler), datainnehåll (vertexSet), datats ursprung (cmdLine), datatransformation (salted), måttenhet (feet), undertyp (int index) och beräknade värden (sum).

Slutsatsen var att programmerare i regel är fullt upptagna med att lösa problemet snarare än att kommunicera lösningen medan de skriver koden — därav den låga andelen namn med extra betydelse utöver typen.

Avslutande diskussion

Föreläsningen sammanfattades som programmering = problemlösning + kommunikation. Avslutande diskussionsfråga att ta med sig: blir kodförståelse (understandability) mindre viktigt när AI skriver koden själv — eller blir den mänskliga förmågan att granska, förklara och verifiera avsikten bakom koden ännu viktigare?

Föreläsning 2: Funktioner

Läsanvisningar inför föreläsning 2

Färgförklaring för chipsen nedan:

• Läs
• Skumma
• Hoppa över

Clean Code

• Ch. 3

Clean Code, 2nd Edition

• Ch. 7
• Ch. 8
• Ch. 9
• Ch. 10
• Ch. 11

Föreläsning

Video (2025)

2025-09-17 1:39:06 · Presentation

Föreläsning 3: Kommentarer

Läsanvisningar inför föreläsning 3

Färgförklaring för chipsen nedan:

• Läs
• Skumma
• Hoppa över

Clean Code

• Ch. 4

Clean Code, 2nd Edition

• Ch. 5

Föreläsning

Video (2025)

2025-09-24 1:15:41 · Presentation

Föreläsning 4: Formatering

Läsanvisningar inför föreläsning 4

Clean Code

• Ch. 5

Clean Code, 2nd Edition

• Ch. 6

Föreläsning

Video (2025)

2025-10-16 1:58:58 · Presentation

Föreläsning 5: Objekt och datastrukturer

Läsanvisningar inför föreläsning 5

Clean Code

• Ch. 6
• Ch. 7
• Ch. 8
• Ch. 9

Clean Code, 2nd Edition

• Ch. 8
• Ch. 12
• Ch. 14
• Ch. 15
• Ch. 25
• Ch. 26

Föreläsning

Video (2025)

2025-10-16 1:45:58 · Presentation