1 of 32

Kodkvalitet

Daniel Toll

2 of 32

Daniel Toll

www.lnu.se

​

Undervisar: Webb, Spel och Testning.

Forskar om: Kodkvalitet

daniel.toll@lnu.se

3 of 32

Intressen

​

​

​

​

​

​

​

4 of 32

Spel och Simuleringar

  • Målet med ett spel är “kul”
  • Målet med simulering är “~korrekt”
  • Frekventa förändringar
  • Komplexa och med “emergent behaviour”
  • Prestanda är viktigt
  • Svårtestade

5 of 32

Mjukvara förändras (eller dör...)

Omgivningen ändras.

​

  • Krav
  • API´er
  • Plattformar
  • Förståelse

​

6 of 32

Diskussionsfråga

Vilka faktorer styr er kod?

​

Under de senaste 12-24 månaderna vilka saker bidrar mest till att er kod förändrats?

​

Vilka delar har varit helt stabila? Varför?

​

7 of 32

Förändring leder till...

8 of 32

Kod och design eroderar

Förlorar information

&

Lämnar rester

&

“Architectural drift”

9 of 32

Ser ej problemet (innan det är mitt)

10 of 32

Lagra information

​

​

11 of 32

Information går förlorad

≈

Vid testning

12 of 32

Feedback

Programmerare behöver enkel och relevant information.

?

13 of 32

Idealet:

  • Informationen är kvar
    • Lättillgänglig information
    • Informationen är lätt att förstå
  • Förändringar genomförs enkelt och säkert.
    • En ändring genomförs, testas, accepteras, koden hinner återställas.
    • Feedback vid fel, alltid.

​

14 of 32

Verkligheten:

  • Informationen är ofta borta
    • Söka, härleda, debugga, återskapa
    • Felaktig information
    • Vi kanske inte ens vill lagra informationen >;)
  • Förändringar är svåra
    • Vi hinner/vill/kan inte återställa koden
    • Vi får inte alltid reda på att något är fel.

15 of 32

Vad gör koden?

16 of 32

Behövs kommentaren?

17 of 32

Diskussionsfråga

Vilka möjligheter har vi att lagra information i kod?

​

Vilken typ av information saknar du oftast?

​

Går all information att lagra?

18 of 32

Implicita begränsningar

Ledtrådar.

  • Dokumentation
  • Kommentarer
  • Manuella tester
  • Namn på identifierare
  • Informationsredundans

Nackdelar: tolkningsbara och inte tvingande.

19 of 32

Identifierare

800K variabler från 56K java projekt

​

~30% variabelnamn är BARA typinformation. Ex View view, String string

(~6.5% av de primitiva datatyperna, ~50% av variabelinstanserna)

20 of 32

Identifierare

Lagrar information om typ(view), roll/relation(child), multiplicitet(names[]), scope(myName), datainnehåll(vertexset), dataursprung(cmdLine), datatransformeringar(salted), enhet(feet), subtyp(int index), beräknat värde(sum) ...

21 of 32

Painted types

String fileName = “dragonfire.png”;

​

float radius = 1.0f;

...

void draw(float size) {...

22 of 32

Kommentarer

En begränsad undersökning av kommentarer i Java

40% av undersökta kommentarer gav ingen extra information…

Ex @param String fileName, the file name

​

​

23 of 32

Linux, FreeBSD, and OpenSolaris

23.1-29.7% av (Linux, FreeBSD, and OpenSolaris) är kommentarer

22.1% förklarar integers

16.8% dataflöde, kontrollflöde och förklaringar av beroenden

10.7% kan utryckas med “annotation languages”

Listening to programmers Taxonomies and characteristics of comments in operating system code

http://dl.acm.org/citation.cfm?id=1555048

​

24 of 32

Begränsa lösningsrymden

25 of 32

Explicita begränsningar

Explicita begränsningar

  • Typsäkerhet
  • const(C++), final(Java)
  • synlighet (public…)
  • asserts och exceptions
  • Exekverande tester (nästa slide)

26 of 32

Exempel JUnit

Korrekt, Lokaliserad, Lagom, Prioriterad, Läsbar, Samlad, Tillräcklig, Rekonstruerbar, Spårbar.

​

27 of 32

När får vi informationen?

28 of 32

Under testning

29 of 32

Under drift

30 of 32

kod som kan ändras

Begränsade beroenden.

Kapslar in kunskap.

  • Lagrar domänkunskapen i kod.
  • Liten redundans och lagom stor kappsäck.
  • Vi får feedback när något är fel.

31 of 32

Bra kod

​

  • Är lätt att förstå
  • Använder spårbara beroenden
  • Använder språkets explicita konstruktioner

32 of 32

Tack!

Daniel Toll

daniel.toll@lnu.se