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