Download - Code Quality - cs.anu.edu.au
![Page 1: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/1.jpg)
Code QualityTesting and Style
![Page 2: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/2.jpg)
What makes for ‘Good Code’?
• Correct
• Fast
• Readable
![Page 3: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/3.jpg)
Ensuring Correctness
Assuming that you’ve dealt with all errors and warnings…
• Reading your code
• Testing your code
• Mathematical proof about your code
![Page 4: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/4.jpg)
The Value of Testing
Testing shows the presence, not the absence of bugs- Edsger W. Dijkstra (1930-2002)
From the same source, I also like:The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim
Photo c/o http://www.cs.utexas.edu/users/EWD/
![Page 5: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/5.jpg)
Black Box vs White box
Black box testing involves writing tests without looking at your code• Motivated by the specification• Indeed, can be written before you write a line of code
White box testing involves writing tests motivated by your code• Be your own enemy - how can I break this code?
![Page 6: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/6.jpg)
What makes a good ‘black box’ test?
Identify testing groups of inputs, and test a ‘typical’ representative of each of them
These groups should collectively cover all possibilities
The division should correspond to different choices the program will need to make• Should behave somehow similarly on inputs from the same group• Should behave somehow differently on inputs from different groups
![Page 7: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/7.jpg)
What makes a good ‘black box’ test?
Pay particular attention to special cases• e.g. on the ‘boundaries’ between groups• Input that is somehow ‘extreme’, e.g. empty input.
These special cases should be tested individually
![Page 8: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/8.jpg)
What makes a good ‘black box’ test?
maxThree :: Int -> Int -> Int -> Int
• The group of inputs where the first is greatest• The group where the second is greatest• The group where the third is greatest• Boundary case: situations where some inputs are equal
![Page 9: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/9.jpg)
What makes a good ‘white box’ test?
Identify points where your program `makes a choice’ on input, and test a ‘typical’ input for each possible choice• case, guards, etc.• base case vs step case of recursions
Focus particularly on inputs on the boundary between choices, or on any overlapping situations
Pay extra attention to _ and otherwise, which can sweep up many different situations
![Page 10: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/10.jpg)
What makes a good ‘white box’ test?
maxThree :: Int -> Int -> Int -> IntmaxThree x y z| x > y && x > z = x| y > x && y > z = y| otherwise = z
The boundary of the first two tests suggests testing e.g. 2 2 1
![Page 11: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/11.jpg)
Recording your tests
Throwing tests at the ghci prompt is probably how you start, but is not a robust approach to testing big or difficult programs• You will forget what you’ve tested so far, so miss possible errors• If you change your code, all your old testing is now useless
Instead, write your unit tests in your code, including the expected output• You can run the same tests repeatedly as your code changes
![Page 12: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/12.jpg)
doctest
A Haskell program that checks all the unit tests in your code, provided they are written in the right format
-- | Compute Fibonacci numbers -- >>> fib 10 -- 55 -- >>> fib 5 -- 5 fib :: Int -> Int
![Page 13: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/13.jpg)
doctest - practicalities
Call doctest MyFileName.hs from outside ghci
Format: The | is essential-- | Compute Fibonacci numbers ✓-- Compute Fibonacci numbers ✖
Format: Indenting, other spacing, has to be perfect-- 5 ✓-- 5 ✖
![Page 14: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/14.jpg)
Randomised testing
Many tests with little effort via randomised testing
We won’t spend lecture time on this, but feel free to read up about Haskell’s QuickCheck library for property-based testing in the textbook or online
Randomised testing is powerful but special cases still need to be thought about• e.g. a program that works on any random Int – except 0
![Page 15: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/15.jpg)
Style
You may have heard people talk about code style
What does this mean?
![Page 16: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/16.jpg)
‘Style’ Sometimes Mean This…
Photos c/o Harper’s Bazaar, Rod Authority, Francesco Giusti & World Press Photo
![Page 17: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/17.jpg)
Style
Style (for us) does not mean flamboyance or expressing individuality
It means writing code in a way that is easy to read
This lecture will give some ideas about achieving this• Worth marks in assignments 2 and 3, and the exam!
Our Style Guide on the website (from UPenn) gives more tips
![Page 18: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/18.jpg)
Who reads your Code?
• You• Colleagues• Including on a joint project at university!
• Future programmers you’ve never met• Code reviewers• In this course, your tutor
![Page 19: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/19.jpg)
Comments
Haskell comments syntax• -- at the start of each line• {- my comments here… -}
Say what the code does, not how it does it• Your audience is not people who don’t know Haskell
A lack of comments is bad – but so are too many!
![Page 20: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/20.jpg)
Comments
There are things you might not think of as comments, but can help to play that role
Type declarations for (top-level) functions give vital information• Never leave them off, even where Haskell can infer them• The type keyword can help to make type declarations more clear
Unit tests can help to explain what a function is for
![Page 21: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/21.jpg)
Names
The names of functions, variables, constructors, and modules are, for the machine, completely arbitrary
Not so for the reader!
Descriptive names turn your code from gibberish to something readable• Not the shortest names possible
Use standard naming conventions – camelCase
![Page 22: Code Quality - cs.anu.edu.au](https://reader031.vdocuments.us/reader031/viewer/2022012508/61846a7401f8dd7d5a124ffd/html5/thumbnails/22.jpg)
Miscellaneous
• No dead code• Minimise repeated code• Use helper functions (or where) to break up big definitions• Avoid unnecessarily long code e.g. by using Prelude functions• Avoid warnings: use _ for unused input• Consistent indentation (spaces not tabs)• Lines 80 characters or less wide• etc...