% total ber¨aknar totalt ˚aterbetalat belopp.
%
% utdata total - total skuld
%
% indata belopp - l˚anat belopp
% rantesats - r¨antesatsen i procent
% manader - l˚anets l¨optid i m˚anader
% period [’m’/’y’] - period
% f¨or vilken r¨antesatsen g¨aller
% m˚aste vara antingen ’m’ f¨or m˚anad
% eller ’y’ f¨or ˚ar.
% om period utl¨amnas antas ˚ar
%
% Sten Hellman 030211
if (nargin == 3); period=’y’; end;
if (period == ’y’)
total = belopp * (1 + rantesats/100) ∧ (manader / 12);
elseif (period == ’m’)
total = belopp * (1 + rantesats/100) ∧ (manader);
else
disp(’ perioden m˚aste anges som m eller y’);
total = -99;
end
Denna funktion kan man sedan kalla fr˚an ett program d¨ar man l¨agger in olika m¨ojliga alter-nativ f¨or att kunna best¨amma vilket som ¨ar mest f¨orm˚anligt:
% kreditkort ett ˚ar till 4.3% i m˚anaden kredit = interest(10000, 4.3, 12, ’m’)
% bank ett ˚ar till 23% per ˚ar bank = interest(10000, 23, 12)
6.5 Programmeringsfilosofi/teori
I denna del kommer vi att ta upp vissa saker som ¨ar bra att f¨ors¨oka att h˚alla i huvudet n¨ar vi b¨orjar skriva program. F¨or att exemplifiera de olika elementen skall vi skriva en allm¨an rutin som ber¨aknar primfaktorer f¨or ett givet tal.
1Man anv¨ander kommandot varargin och t¨anker ut tester som kan avg¨ora vilka argument som faktiskt l¨amnades.
6.5. PROGRAMMERINGSFILOSOFI/TEORI 57 6.5.1 Design av programmet
Den viktigaste delen av programmerandet b¨orjar egentligen innan vi skrivit ett enda Octave-kommando, n¨amligen design-fasen. Innan vi b¨orjar skriva in en massa kommandon b¨or man sitta ned och t¨anka igenom vilka steg programmet skall utf¨ora, i vilken ordning och vad som
¨
ar de m¨ojliga utfallen under det att programmet k¨or. Nuf¨ortiden finns det program som hj¨alper till i den h¨ar fasen och som ibland till och med skriver programkoden automatiskt n¨ar man v¨al en g˚ang p˚a ett symboliskt s¨att best¨amt vad programmet skall utf¨ora. Men man kommer ganska l˚angt med ett gammalt hederligt fl¨odesschema, en slags ”ritning” ¨over programmet. Det finns v¨al definierade regler f¨or hur man skall rita ett fl¨odesschema, h¨ar skall vi inte g˚a in i n˚agra detaljer2 utan f¨oljer bara konventionen att beslut fattas i rombiska boxar, medan processer sker i vanliga rektanglar. Som exempel visar vi ett fl¨odesschema f¨or ett program som ber¨aknar primfaktorer f¨or ett godtyckligt tal:
Bara genom att g¨ora en s˚adan h¨ar enkel liten skiss dyker det upp m˚anga viktiga aspekter av programmet som man kanske inte t¨anker p˚a fr˚an b¨orjan, som till exempel att vi m˚aste avdela en variabel f¨or att lagra de primfaktorer som poppar upp. Vi ser ocks˚a tydligt vilka data som skall in i programmet (x, det tal vi s¨oker faktorer f¨or) och vad som skall ut (antal primfaktorer och vilka de ¨ar). Vi ser ocks˚a att en viss del av koden kommer att upprepas ett stort antal g˚anger f¨or olika v¨arden p˚a variabeln i.
Studerar man schemat en stund till inser man att programmet, som det ¨ar designat i figuren, kommer att testa alla faktorer udda som j¨amna vilket naturligtvis inte ¨ar n¨odv¨andigt eftersom
2I ritverktyget i OpenOffice (“Show Draw Functions” i verktygslisten ¨oppnar en separat verktygslist f¨or ritverktyg) finns en meny (“Flow-charts”) som inneh˚aller olika symboler f¨or ett fl¨odesschema.
58 KAPITEL 6. PROGRAMMERING den enda m¨ojliga j¨amna faktorn ¨ar tv˚a. Det ¨ar d˚a dags f¨or steg 2: omdesign. I det h¨ar fallet v¨aljer man l¨ampligen att f¨orst testa p˚a faktorn tv˚a tills man har ett udda tal kvar, och sedan testa fr˚an 3 och upp˚at med alla udda tal (byt i = i + 1 mot i = i + 2).
Ett bra fl¨odesschema skall bryta ned programmet i avskilda block som utf¨or en specifik uppgift, visa vilka grenpunkter (villkor) som finns i programmet och hur dessa leder till att olika delar av koden utf¨ors. Vidare skall vilka data som utbyts mellan programmet och dess omgivning - det s˚a kallade gr¨anssnittet - vara tydligt.
6.5.2 Dokumentation av programmet.
Vi har tidigare ber¨ort vikten av att dokumentera program med kommentarer i koden. F¨or stora program r¨acker inte detta s¨att att dokumentera vad programmet g¨or, och vilket dess gr¨anssnitt mot omv¨arlden ¨ar. Om programmet b¨orjar omfatta tusentals rader med kod ¨ar det inte praktiskt att bl¨addra igenom koden p˚a jakt efter kommentarer som avsl¨ojar allt om programmet. I s˚adana fall b¨or man producera en separat dokumentation som talar om hur man anv¨ander programmet, vad programmet utf¨or och vad som kr¨avs f¨or att programmet skall kunna k¨ora (till exempel vilka data som m˚aste matas in i programmet och i vilket format). Den h¨ar typen av dokumentation - Anv¨andarhandbok, engelska Users Guide - skall kunna l¨asas av n˚agon som inte har n˚agra egentliga kunskaper i det programmeringsspr˚ak som anv¨ants i det aktuella fallet. D¨aremot ¨ar det viktigt att dokumentera till exempel matematiska algoritmer som anv¨ands av programmet om dessa har betydelse f¨or hur man skall f¨orst˚a resultaten. Inom den h¨ar kursen ¨ar det knappast troligt att ni kommer att skriva s˚apass stora program att de beh¨over dokumenteras p˚a den h¨ar niv˚an, i allm¨anhet kommer kommentarer i koden att r¨acka till.
Verkliga proffs l˚ater dokumentationen av programmet ing˚a i design-fasen, jag har sj¨alv sett exempel p˚a duktiga programmerare som f¨orst har utarbetat dokumentationen av programmet och diskuterat den med anv¨andarna av programmet i olika omg˚angar tills de varit n¨ojda, och f¨orst d¨arefter b¨orjat arbetet med att skriva programmet. Det ¨ar v¨al kanske on¨odigt att till¨agga att de flesta av oss inte alls lever som vi l¨ar utan s¨atter oss ned och f¨ors¨oker koda programmet rakt av och g¨ora n˚agon slags ”design as you go”. Har man lite vana fungerar det ocks˚a, f¨or det mesta, men vi skulle nog skriva b¨attre program, och f˚a dem klara lite tidigare, om vi lade ned lite mer m¨oda p˚a design och dokumentation.
6.5.3 Goda vanor
Det finns n˚agra goda vanor som man b¨or l¨agga sig till med n¨ar man skriver kod f¨or dator-program. Gemensamt f¨or m˚anga av dessa vanor ¨ar att om man skriver en kort kodsnutt p˚a ett par rader s˚a kostar det mer tid att till¨ampa de goda vanorna ¨an att l˚ata bli. Man slarvar d¨arf¨or ofta och hafsar bara ner n˚agra rader kod som fungerar f¨or stunden. Det h¨ar beteendet
¨
ar ganska universellt, universellt ¨ar ocks˚a att det n¨astan alltid straffar sig i l¨angden! Korta koder om n˚agra f˚a rader v¨axer f¨or det mesta ut till l¨angre program, och f¨orr eller senare kommer man till den punkt d¨ar man ger upp f¨ors¨oken att h˚alla reda p˚a vad som h¨ander i en ostrukturerad m-fil, och b¨orjar g˚a igenom den igen fr˚an b¨orjan f¨or att “st¨ada upp”. Det h¨ar tar alltid mycket mer tid ¨an vad det skulle ha tagit att g¨ora det r¨att fr˚an b¨orjan. Listan nedan ¨ar sj¨alvklart inte komplett, men ger ett skelett att b¨orja bygga dina egna program-meringsvanor p˚a. Kommer du p˚a n˚agot som du tycker borde finnas med s˚a h¨or g¨arna av dig s˚a kan vi inkludera ditt tips i kommande upplagor. Och till slut - minns att listan ¨ar tips och f¨orslag, var och en hittar till slut sin egen stil n¨ar det g¨aller programmering.
• Var konsekvent och logisk n¨ar du namnger variabler. Ge variablerna namn som betyder n˚agot, utan att g˚a till ¨overdrift. Best¨am dig f¨or om du vill anv¨anda stor bokstav eller understrykning n¨ar du binder ihop ord (FallTid eller fall tid) f¨or att skapa namn