code quality - cs.anu.edu.au
Post on 05-Nov-2021
1 Views
Preview:
TRANSCRIPT
Code QualityTesting and Style
What makes for ‘Good Code’?
• Correct
• Fast
• Readable
Ensuring Correctness
Assuming that you’ve dealt with all errors and warnings…
• Reading your code
• Testing your code
• Mathematical proof about your code
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/
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?
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
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
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
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
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
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
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
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 ✖
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
Style
You may have heard people talk about code style
What does this mean?
‘Style’ Sometimes Mean This…
Photos c/o Harper’s Bazaar, Rod Authority, Francesco Giusti & World Press Photo
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
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
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!
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
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
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...
top related