Läsbar prolog 8.1-8.3 CM 8.1. allmäna principer correctness user-friendliness efficiency readability modifiability robustness documentation.

En presentation över ämnet: "Läsbar prolog 8.1-8.3 CM 8.1. allmäna principer correctness user-friendliness efficiency readability modifiability robustness documentation."— Presentationens avskrift:

1 läsbar prolog 8.1-8.3 CM 8.1

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

3 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!

4 ’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?

5 efficiency tidseffektivitet minneseffektivitet alltså: optimering helt enkelt

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

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

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

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

10 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)

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

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

13 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

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

15 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

16 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…

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

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

19 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

20 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

21 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

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

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

24 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!

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

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

27 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.

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

29 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, …)

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

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

32 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!

33 kommentering (forts.) författare + e-post versionsnummer datum (’timestamp’) ev. copyright och licensinformation (t ex http://www.gnu.org/copyleft/gpl.html)

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

35 generellt allmänna riktlinjer för programmering (datalingvistiskt perspektiv): http://nlpfarm.sourceforge.net/develop.html

36 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!)