Föreläsning 1 – Meningsfulla namn

Läsanvisningar

Läs innan föreläsningen

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

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?