läsbar prolog CM 8.1

allmäna principer correctness user-friendliness efficiency readability modifiability robustness documentation

correctness ett program bör fungera som det ska otroligt nog ofta förbisett: speciellt om elegans, effektivitet och optimering får mer och mer utrymme!

’user-friendliness’ lätt att använda och interagera med vad betyder det egentligen? enormt begrepp som kan innefatta allt möjligt –t ex vem är ”user” i det här fallet? –och i vilket sammanhang?

efficiency tidseffektivitet minneseffektivitet alltså: optimering helt enkelt

readability kommentering i koden programmeringsstil alltså: lättförståelig kod

modifiability lätt att bygga ut programmet lätt att förändra programmet modularisering ett ”rent API” (application programming interface)

robustness felhantering felrapportering (istället för krasch!)

documentation kommentarer i koden API-specifikation designdokument (för att kommunicera idén med programmet)

allmänna principer alla dessa principer hänger så klart ihop t ex läsbarhet kopplat till dokumentation och ”användar- vänlighet” (där ”användaren” är en programmerare i det här fallet)

hur uppnår vi dessa principer? genom att ha koll på, och följa en designprocess genom praktiskt erfarenhet (projektet!)

processen definiera problemet FÖRST (”pappersprogrammering”) steg-för-stegbyggande (’iterativ utveckling’) gradvis förfining

processen (forts.) känna igen ’mönster’ –programmeringsmässigt (t ex rekursion) –deklarativt eller procedurellt? (beror på problemet) –(bildliga) representationer (stack, träd, lista, …) …och veta vilka mönster som passar ett specifikt problem

processen (forts.) top-level solution iterativ utveckling bottom-level solution

1 ’top-level solution’ –tänk igenom problemet: skissa! –försök definiera ’sub-problem’ –formulera och omformulera (på ett abstrakt plan) –använd kraftfulla representationer! (bilder, diagram, …) –gäller både procedurer, algoritmer, relationer och datastrukturer

2 ’iterative development/increments’ –omdefiniera, omstrukturera och förfina –var INTE rädd för att kasta och börja om (vägen dit har redan skänkt förståelse) –idéer, kreativitet och inspiration…

3 ’bottom-level solution’ –själva koden (exekverbar men kanske inte optimerad?) –…men det tar vi på föreläsning om ”effektiv prolog”

processen (forts.) top-level solution iterativ utveckling bottom-level solution skisser, diagram, ’pappersprogrammering’ diagram & kod kod

sub-problem så hur hittar vi lämpliga sub-problem? –vi lär oss att känna igen problem vi stött på förut (mönster) t ex rekursionsmetaforen –hitta basfallet (triviala fallet) –hitta generella fall där lösningen består av enklare varianter av ursprungs- problemet

bildrepresentationer deklarativt språk (sekvens eller ’ordning’ spelar inte så stor roll i bilder) datastrukturer (t ex träd) lämpar sig för bilder (av just träd!) relationer mellan objekt lättare att rita än att beskriva i ord

generalisering lyckas man formulera det generella problemet faller ofta en rekursion ut (vilket är ett mönster vi är vana vid att implementera) detta underlättar också framtida återanvändning

dagens ämne: läsbarhet, vilket främst innefattar principerna: –läsbarhet –dokumentation

läsbarhet kort och tydligt: –korta klausuler –korta procedurer –följer ofta automatiskt om ’sub- problemen’ är noggrant definierade

läsbarhet (forts.) bra namn (indikera vad procedurer och variabler har för mening) ett ’bra’ namn är också lätt att komma ihåg välj en ”standard” och håll fast den!

exempel a(X,Y,Z)% säger inte speciellt mycket append(List1,List2,Result)%tydligare

läsbarhet (forts.) luft och vitutrymme –använd tabbar –använd blanka rader

exempel s(N,N,N).s(N,M,S):-N<M,N1 is N+1,s(N1,M,DSU),S is N+DSU. s(N,N,N). s(N,M,S):- N<M,N1 is N+1,s(N1,M,DSU),S is N+DSU. s(N, N, N). s(N, M, S) :- N < M, N1 is N+1, s(N1, M, DSU), S is N+DSU. summera(N, N, N). summera(N, M, Summa) :- N < M, N1 is N+1, summera(N1, M, Delsumma), Summa is N + Delsumma.

kommentering % enradig kommentar /* flerradig kommentar */ fokusera på vad programmet gör, och hur man använder det därefter förklara individuella predikats funktionalitet

kommentering (forts.) vilket predikat används först? –förväntade resultat –exempel på körningar speciella systemkrav –operativsystem –prolog-version –hårdvarukrav (varna för långa körningar, hög minnesåtgång, …)

kommentering (forts.) kort summering av grundläggande koncept i systemet hänvisning till dokumentationen

kommentering (forts.) beskriv predikatnamn etc. konsekvent: ”PredikatNamn / Aritet” append/3

kommentering (forts.) använd kommentarer för att förklara kod som inte är självklar! –dvs glöm inte att förklara! –men förklara heller inte självklarheter behövs mycket förklaringar? –kommentera inte dålig kod – skriv om den istället!

kommentering (forts.) författare + e-post versionsnummer datum (’timestamp’) ev. copyright och licensinformation (t ex

readme readme-filen: –mellanting mellan kommentarer och dokumentation tillägg till dokumentation (senaste ändringar)

generellt allmänna riktlinjer för programmering (datalingvistiskt perspektiv):

vanliga misstag glömt punkten, eller ersatt med ’,’ inget whitespace efter punkten (t ex glömt trycka return efter sista punkten i filen…) mismatchade par. (t ex ’[’ och ’]’ eller ’/*’ och ’*/’). felstavnign av predikat (speciellt inbyggda är svåra att hitta) –likartade namn som matchar (t ex råkar skriva ’appends’ för append, och jag har definierat ett predikat som heter appends som gör nåt helt annat!)