Hårdkodning – Wikipedia

Den här artikeln behöver källhänvisningar för att kunna verifieras. Motivering: Saknar helt fotnoter. (2016-02) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan.

Hårdkodning är en programmeringsterm som innebär att ett eller flera värden i ett datorprogram inte kan ändras, till skillnad mot värden som kan omdefinieras i konfigurationsfiler eller databaser, i samband med att programmet startas eller som programmet hämtar från operativsystemet eller på annat sätt kan anpassa under körningen. Hårdkodning innebär att man inte använder variabler vilkas värden dynamiskt kan ändras utan istället skriver det önskade värdet som sådant (en så kallad litteral konstant) i programmets källkod.

Ifråga om till exempel inbyggda system kan man med hårdkodning mena att någonting är kodat rent fysiskt, såsom genom hur komponenter kopplats.

Ett visst värde kan anges explicit i programkoden då värdet skall användas. Detta är det enklaste sättet att ange värdet och används ofta i preliminär kod eller i samband med tester. Det hårdkodade värdet kan bli kvar av misstag, slarv eller för att värdet ifråga inte anses behöva kunna ändras.

Om värdet definieras som en konstant, men också en hårdkodad variant används någonstans i programmet, kan resultatet bli svårhittade fel, i synnerhet om det hårdkodade värdet används bara i specialfall.

Normal praxis är att definiera konstanter i början av programmet (då konstanten används i en enstaka programfil i ett litet program), i särskilda definitionsfiler (*.h, *.def e.d.) eller i styrfilerna för själva kompileringen. Då konstanten inte är specifik för programmet ifråga definieras den i allmänhet genom externa programbibliotek eller deras definitionsfiler.

Hårdkodning som konstanter definierade på logiska ställen i källkoden är inte ett stort problem i de fall konstanten inte normalt behöver ändras annat än av experter med tillgång till källkoden. Detta gäller till exempel för fria serverprogram för unixliknande system.

Ifråga om "proprietär programvara", såsom den mesta programvaran för Windows, har den som använder programmet sällan möjlighet att ändra i koden eller ens att få tillverkaren att ändra koden. Var i koden värdet är definierat är då av mindre betydelse, värdet är ändå svårt att anpassa till olika behov.

I vissa fall är programmet skrivet att utnyttja antaganden om speciella egenskaper hos en storhet. Om ett program implicit använder det faktum att födelsedatum och kön framgår ur det svenska personnumret kan programmet vara svårt anpassa till andra länders system – eller för utländska medborgare i Sverige. Om detta faktum däremot används i en särskild modul och födelsedatum och kön lagras i skilda variabler, kan modulen lätt bytas ut mot en som använder andra system. Jämför portering.

Ett särskilt problem gäller de situationer då inte värdet i sig är hårdkodat, men däremot det hur det representeras i programmet. Årtal kan ofta representeras som två siffror, men detta blir ohållbart då längre tider skall hanteras. Variabler som representeras i 32 bit hanteras effektivt på 32 bits maskiner, men kan leda till problem vid övergång till 64 bit.

Hurdana variabeltyper som skall väljas och hur typerna skall kodas är ofta ett svårt problem, då effektivitetsaspekter, samspel mellan olika programbibliotek och olika programmeringstraditioner spelar in. Väldefinierade gränssnitt är dock viktiga för att minimera problemen; implicita antaganden bör undvikas så långt som möjligt.

I allmänhet kan olika värden då programmet startas läsas in från en konfigurationfil, där de vid behov lätt kan ändras, eventuellt också som omgivningsvariabler och som flaggor då programmet startas. Val av metoder varierar beroende på hur ofta värdet bedöms kunna ändras. Förvalda värden kan vara inbyggda som konstanter i programmet, så att bara ändrade värden behöver anges på andra sätt.

Operativsystemet kan erbjuda sätt att hämta olika värden, till exempel fås hemkatalogen i Unix genom biblioteksanropet getpwent och genom omgivningsvariabeln HOME. Det förra används då man är beroende av ett korrekt värde, den senare då man vill erbjuda flexibilitet åt användaren. Motsvarande funktion finns i Windows.

Ofta kan programmets egna rutiner för olika ändamål ersättas med externa program eller programbibliotek. I Unix är det praxis att låta användaren välja sin textredigerare, också till exempel vid skrivande av e-post och ifyllande av webblanketter. Programmets egen slumptalsgenerator eller matematikbibliotek kan ofta med fördel bytas mot externa program eller programbibliotek, då goda sådana finns tillgängliga.

Förutom värden som mer eller mindre av misstag blir kvar i preliminär kod eller kod skriven för testningsändamål används hårdkodning också avsiktligt i de slutgiltiga versionerna av ett program.

Den viktigaste orsaken att använda hårdkodade värden är att man antar att värdet aldrig behöver ändras. Antagandet brukar för det mesta visa sig felaktigt, såsom ifråga om användares hemkatalog eller tolkning av tvåsiffriga årtal.

I vissa fall är värden hårdkodade av säkerhetsskäl:

• väntetider för undvikande av överlastade nät (enligt gällande standard)
• maximal paketstorlek i nätverksprotokoll (jfr ping of death)
• omgivning vad gäller program som skall köras med stora rättigheter (suid)

Det är ändå naivt att lita på att detta hindrar avancerade användare från att ändra konstanterna, antingen genom att skriva egen kod eller genom att ändra konstanterna i själva binärkoden.

Hårdkodade värden används i försök att hindra användning av olagliga kopior av ett program, till exempel så att en nyckel härledd ur den använda maskinvaran eller ur i på den ursprungliga program-CD:n introducerade "fel" hårdkodas i programkoden. Sådana system leder lätt till att också den som lagligen köpt programmet förhindras att använda det i olika specialsituationer.

Förutom direkta fel vid kvarbliven hårdkodning innebär hårdkodning förlorad flexibilitet. I vissa fall kan användningen av program förhindras helt.

• Ett program som förutsätter att hemkatalogen är på ett visst ställe kan bli mer eller mindre obrukbart då hemkatalogen är annanstans, till exempel då den finns på en server. Test med alternativ miljö kan också bli avsevärt svårare.
• Ett program som vill hitta en viss kod på en CD-skiva kan inte användas på en tunn klient som saknar CD-läsare eller då läsaren gått sönder. Det finns ännu datorspel som förutsätter inmatande av rätt diskett!
• Ett program skrivet för att kunna hantera datamängder av viss storleksordning, då dåtida datorer svårligen kunde klara större data, kan inte dra nytta av explosionsartat växande datorprestanda.

• Programmeringsparadigm