b'\n_START_ARTICLE_\nProgrammering\n_START_PARAGRAPH_\nProgrammering g\xc3\xa5r ud p\xc3\xa5 at udvikle computerprogrammer (software) til elektronisk databehandling p\xc3\xa5 en computer ved hj\xc3\xa6lp af et programmeringssprog. Form\xc3\xa5let med et program er overordnet at modtage nogle input-data, udf\xc3\xb8re en opgave p\xc3\xa5 disse (f.eks. beregninger, udskrivning, kommunikation med database) og som resultat tilbagelevere nogle output-data.\n_START_SECTION_\nProgrammeringsprocessen\n_START_PARAGRAPH_\nUdviklingen af et program er en proces best\xc3\xa5ende af det at skrive kildekode, testning, fejlretning (ogs\xc3\xa5 kaldet aflusning, eng. debugging) og vedligeholdelse af kildekoden. Programmet skrives som regel som ren tekst i et programmeringssprog, som har en defineret syntaks for koden. Hvis der er tale om et compileret sprog, overs\xc3\xa6ttes (compileres) kildekoden f\xc3\xb8rst til maskinkode eller et anden mere maskinn\xc3\xa6r kode. I denne compilering opdages ogs\xc3\xa5 eventuelle syntaksfejl. Den oversatte maskinkode kan derefter k\xc3\xb8res af computeren. Hvis der er tale om et fortolket sprog, k\xc3\xb8rer fortolkeren programmet direkte fra kildekoden, og f\xc3\xb8rst undervejs i k\xc3\xb8rselen opdages eventuelle syntaksfejl._NEWLINE_Programmeringen er en del af hele systemudviklingsprocessen, og foruds\xc3\xa6tningen for at programmere er, at der f\xc3\xb8rst er gennemf\xc3\xb8rt en analyse af, hvilke krav systemet skal opfylde over for brugerne. Dette er beskrevet i en kravspecifikation. Herefter designes systemet, og programmeringen gennemf\xc3\xb8res._NEWLINE_Der er en l\xc3\xb8bende debat om hvorvidt kodning af programmer er en kunst, et h\xc3\xa5ndv\xc3\xa6rk eller en ingeni\xc3\xb8r disciplin. Generelt anses god programmering for at en afm\xc3\xa5lt anvendelse af alle tre, hvor m\xc3\xa5let er at producere en effektiv software-l\xc3\xb8sning som kan videreudvikles. Disciplinen afviger fra mange andre tekniske professioner, da programm\xc3\xb8rer, generelt set, ikke beh\xc3\xb8ver licens eller bevis p\xc3\xa5 en standardiseret (eller offentligt reguleret) certifikation for at kalde sig selv "programm\xc3\xb8rer" eller endda "softwareingeni\xc3\xb8r".\n_START_SECTION_\nVariable og konstanter\n_START_PARAGRAPH_\nEn datav\xc3\xa6rdi placeres ofte i en eller flere variable (pladsholder). En variabel er kendetegnet ved et alfanumerisk variabelnavn og en bestemt datatype, men dens konkrete v\xc3\xa6rdi kan skifte undervejs i programmet. Har man brug for en pladsholder, der ikke m\xc3\xa5 skifte v\xc3\xa6rdi, har de fleste sprog mulighed for at definere en konstant.\n_START_SECTION_\nForgreninger\n_START_PARAGRAPH_\nForgreninger er noget af det mest basale i et program, fordi grundlaget for computerberegninger netop er forgreninger, hvor der overalt evalueres p\xc3\xa5, om noget er sandt eller falsk. For at en algoritme ikke blot er en line\xc3\xa6r sekvens af beregninger, men kan variere beregningerne afh\xc3\xa6ngig af de givne data, er man n\xc3\xb8dt til at vurdere p\xc3\xa5, hvorvidt en betingelse er opfyldt eller ej. Enhver forgrening indledes derfor med en betingelse. Forgreninger kan ogs\xc3\xa5 v\xc3\xa6re indlejrede i hinanden (eng. nested), s\xc3\xa5 man kan g\xc3\xa5 tre eller flere veje det givne sted i algoritmen._NEWLINE_I de \xc3\xa6ldste programmeringssprog implementerede man forgreninger ved hj\xc3\xa6lp af etiketter (eng. labels) ved bestemte s\xc3\xa6tninger eller linienumre kombineret med GOTO-s\xc3\xa6tninger, der fortalte, hvor i programmet man skulle g\xc3\xa5 hen. GOTO-s\xc3\xa6tninger kunne dog nemt medf\xc3\xb8re fejl i programmets flow, fordi der til enhver "gren" i en forgrening skulle v\xc3\xa6re en GOTO-s\xc3\xa6tning b\xc3\xa5de for at starte p\xc3\xa5 grenen og for at afslutte den. I dag har man andre metoder til at vise, at en gruppe s\xc3\xa6tninger h\xc3\xb8rer sammen i en "gren". Som regel bruger man n\xc3\xb8gleord som IF ... THEN ... ELSE ... for at implementere en forgrening, eller SWITCH ..., SELECT ... el.lign. ved en bredere forgrening.\n_START_SECTION_\nL\xc3\xb8kker\n_START_PARAGRAPH_\nHvis en gruppe s\xc3\xa6tninger skal udf\xc3\xb8res flere gange, indf\xc3\xb8rer man en l\xc3\xb8kke i programmet. Ogs\xc3\xa5 her skal der anvendes en betingelse, der skal evalueres hver gang en iteration i l\xc3\xb8kken indledes eller afsluttes. Et meget vigtigt element i programmeringen af en l\xc3\xb8kke er at sikre sig, at gruppen af s\xc3\xa6tninger i l\xc3\xb8kken \xc3\xa6ndrer p\xc3\xa5 data p\xc3\xa5 en s\xc3\xa5dan m\xc3\xa5de, at betingelsen p\xc3\xa5 et tidspunkt f\xc3\xa5r programmet til at hoppe v\xc3\xa6k fra l\xc3\xb8kken. Hvis ikke, g\xc3\xa5r programmet ind i en uendelig l\xc3\xb8kke med fatale f\xc3\xb8lger for dets gennemf\xc3\xb8relse._NEWLINE_Ogs\xc3\xa5 l\xc3\xb8kker blev i de \xc3\xa6ldste programmeringssprog implementeret vha. GOTO-s\xc3\xa6tninger, og ligesom i en forgrening kunne det v\xc3\xa6re komplekst at placere GOTO-s\xc3\xa6tninger rigtigt i programmet. I dag er l\xc3\xb8kker implementeret med n\xc3\xb8gleord som f.eks. WHILE ... DO ... , REPEAT ... UNTIL ... eller FOR ... NEXT ... .\n_START_SECTION_\nFunktionskald\n_START_PARAGRAPH_\nHvis man har brug for at udf\xc3\xb8re den samme type beregninger flere steder i et program, eller hvis en gruppe s\xc3\xa6tninger h\xc3\xb8rer s\xc3\xa5 meget sammen i forhold til s\xc3\xa6tningerne omkring dem, at man har et \xc3\xb8nske om at "pakke dem ind", kan man med fordel oprette en funktion (kaldes ogs\xc3\xa5 procedure, (sub)rutine, metode). Funktionen kan modtage \xc3\xa9n til flere parametre som sine "input-data", og den kan tilsvarende returnere et resultat som "output-data". De steder i programmet, hvor beregningerne skal udf\xc3\xb8res, gennemf\xc3\xb8rer man s\xc3\xa5 et kald af funktionen med nogle aktuelle v\xc3\xa6rdier som parametre, og en eventuelt returv\xc3\xa6rdi fra funktionskaldet kan man s\xc3\xa5 opfange og arbejde videre med. En fordel ved funktioner er, at variable, som kun oprettes af hensyn til beregningerne internt i funktion, kan erkl\xc3\xa6res lokalt i funktionen, s\xc3\xa5 andre dele af programmet ikke kan manipulere, endsige se dem._NEWLINE_Funktionskald var sv\xc3\xa6re at gennemf\xc3\xb8re, da man kun havde GOTO-s\xc3\xa6tninger til r\xc3\xa5dighed. Det kunne lade sig g\xc3\xb8re med lidt datadisciplin, for alle variable, ogs\xc3\xa5 de lokale i funktionen, kunne i princippet anvendes overalt (globalt). I det mindste skulle b\xc3\xa5de parametrene og returv\xc3\xa6rdierne (gr\xc3\xa6nsefladen mellem det kaldende sted i programmet og funktionen), anvendes b\xc3\xa5de inden for og uden for funktionens gruppe af s\xc3\xa6tninger. Endelig skulle der v\xc3\xa6re en variabel, der viste, hvilken etiket programmet skulle returnere til, n\xc3\xa5r funktionen var f\xc3\xa6rdig. Endnu mere komplekst blev det, hvis man skulle lave en s\xc3\xa5kaldt rekursion, hvor en funktion internt i sine beregninger kalder sig selv. Da hver funktionskald skulle kunne finde tilbage til det kaldende sted i programmet, var man n\xc3\xb8dt til programmeringsm\xc3\xa6ssigt at lave en begr\xc3\xa6nsning for, hvor mange rekursive kald der kunne v\xc3\xa6re inden i hinanden.\n_START_SECTION_\nStruktureret programmering\n_START_PARAGRAPH_\nDen omfattende brug af GOTO-s\xc3\xa6tninger i implementeringen af forgreninger, l\xc3\xb8kker og funktionskald kunne meget nemt f\xc3\xb8re til uoverskuelig spaghettikode. Is\xc3\xa6r var det begr\xc3\xa6nsningerne ved funktionskald, der fremkaldte et behov for at kunne "indhegne" en gruppe sammenh\xc3\xb8rende s\xc3\xa6tninger i en blok, f.eks. med en parentetisk BEGIN ... END-struktur eller andre typer parenteser. S\xc3\xa5danne blokke anvendes b\xc3\xa5de omkring de s\xc3\xa6tninger, der skal udf\xc3\xb8res i en forgrening og en iteration i en l\xc3\xb8kke, men de er is\xc3\xa6r anvendelige til at erkl\xc3\xa6re funktioner med parametre, returv\xc3\xa6rdier og lokale variable. Sammen med de nye sprog med s\xc3\xa5danne faciliteter opstod programmeringsparadigmet struktureret programmering._NEWLINE_I de fleste sprog designet til struktureret programmering har man ogs\xc3\xa5 muligheden for at erkl\xc3\xa6re en funktion inde i "kroppen" af en anden funktion. P\xc3\xa5 den m\xc3\xa5de kan en funktion ikke kun indeholde lokale variable, men ogs\xc3\xa5 lokale funktioner. Der g\xc3\xa6lder nemlig som regel, at lokale variable eller funktioner i en funktion ikke kan "ses" udefra; man taler om, at deres scope kun er funktionen selv eller funktioner erkl\xc3\xa6ret inde i funktionen. I sprog, hvor dette ikke g\xc3\xa6lder automatisk, er det op til programm\xc3\xb8ren selv at udvise datadisciplin ved anvendelsen af variable. Udover at undg\xc3\xa5 anvendelsen af GOTO-s\xc3\xa6tninger er konsekvens omkring variables og funktioners scope nok det vigtigste middel til at undg\xc3\xa5 spaghettikode i struktureret programmering.\n_START_SECTION_\nKompleksitet\n_START_PARAGRAPH_\nStruktureret programmering \xc3\xa5bner ogs\xc3\xa5 st\xc3\xb8rre muligheder for at arbejde med abstrakte datatyper, dvs. komplekse datastrukturer, der vha. reference-typer (pegere/pointere), post-typer og specielle funktioner er optimeret til at kunne udf\xc3\xb8re f.eks. inds\xc3\xa6ttelse af elementer eller s\xc3\xb8gning efter elementer. Med de st\xc3\xb8rre muligheder blev der ogs\xc3\xa5 st\xc3\xb8rre behov for at vurdere effektiviteten af et program, s\xc3\xa6rligt med henblik p\xc3\xa5 en algoritmes kompleksitet. Hermed menes en vurdering af, i hvilket omfang beregningstiden i algoritmen vokser, n\xc3\xa5r datam\xc3\xa6ngden stiger. Hermed fik programm\xc3\xb8ren redskaber til at finde frem til den mest effektive algoritme for sit program.\n_START_SECTION_\nObjektorienteret programmering\n_START_PARAGRAPH_\nI de f\xc3\xb8rste computere interagerede brugeren ved hj\xc3\xa6lp af en tekstbaseret kommandolinjegr\xc3\xa6nseflade til computerens styresystem. P\xc3\xa5 en kommandolinie kalder man f.eks. programmet ved at skrive dets navn efterfulgt af eventuelle parametre som input. N\xc3\xa5r programmet har udf\xc3\xb8rt sin opgave, svarer den tilbage med eventuelt tekst-output og giver brugeren mulighed for at indtaste en ny kommando. Der er tale om en s\xc3\xa5kaldt line\xc3\xa6r kommunikation mellem bruger og computer, hvor \xc3\xa9n af dem hele tiden venter p\xc3\xa5 den anden._NEWLINE_Med fremkomsten af computere med en grafisk brugergr\xc3\xa6nseflade (GUI, fra eng. Graphical user interface) blev b\xc3\xa5de input og output v\xc3\xa6sentligt mere komplekst. Brugeren kan ikke blot levere tekstinput flere forskellige steder p\xc3\xa5 sk\xc3\xa6rmen, men der kommunikeres ogs\xc3\xa5 ved hj\xc3\xa6lp af forskellige enheder som tastatur, mus og scanner, og der er ingen regler for, hvilken r\xc3\xa6kkef\xc3\xb8lge kommunikationen foreg\xc3\xa5r. Computeren k\xc3\xb8rer med flere tr\xc3\xa5de._NEWLINE_Dette satte skub i udviklingen af objektorienteret programmering. I dette programmeringsparadigme arbejder man med begrebet et objekt, som er defineret som en helhed med identitet, tilstand og adf\xc3\xa6rd. S\xc3\xa5danne objekter kan eksempelvis v\xc3\xa6re de enkelte komponenter, som et sk\xc3\xa6rmbillede er opdelt i, eller de forskellige stykker hardware, som brugeren anvender. Men det kan ogs\xc3\xa5 v\xc3\xa6re genstande eller begreber fra it-systemets problemomr\xc3\xa5de, den del af systemets omverden, som systemet skal afspejle. Det er opgaven for objektorienteret analyse og design at finde frem til, hvilke objekter der skal medtages._NEWLINE_Desuden kan et objekt v\xc3\xa6re en avanceret datastruktur til at manipulere en dynamisk samling af variable af samme datatype, optimeret til s\xc3\xb8gning eller sortering eller hurtig inds\xc3\xa6ttelse og fjernelse af elementer.'