Transcript assert

Thought for the Day
“Discipline is the refining fire by which talent
becomes ability.”
– Roy L. Smith
Writing Good Programs
• Criteria for judging software quality:
–
–
–
–
–
–
–
–
Correctness
Ease-of-use
Generality
Efficiency
Portability
Clarity
Ease of coding and testing
Ease of modification
Quality Criteria (cont.)
• Generality and Efficiency
– Often in tension
– Try to solve a class of problems, not just one
specific problem
• Portability
– Keep to standard features
Quality Criteria (cont.)
• Clarity
– How easily can the program be understood?
• Well-structured program
• Comments
• Good names for variables, methods and classes
– Follow conventions for identifier names
• Simplicity of algorithm
• Good layout
– Indentation, etc.
Quality Criteria (cont.)
• Ease of Coding and Testing
– Well structured (modular) programs
– Leave test code in program (commented out if
necessary)
• Ease of Modification
– Well written program
– Modular design
Techniques for Improving
Program Quality
• Preconditions and Postconditions
• Assertions
• Automatic system documentation
Preconditions and Postconditions
• We can characterise a method by the
program’s state before and after the method
is executed
“Before and After”
Preconditions and Postconditions
• Preconditions
– Assumptions about the “before” state
• Postconditions
– Statements about the “after” state
• Often expressed as comments
Example
• A method to calculate a square root
public double squareRoot (double x)
// PRE: x >= 0
// POST: squareRoot returns an approximation
//
to the square root of x
{ ...
} // squareRoot
Another Example
• Some methods have no preconditions
• A random number method:
public double random ()
// PRE: None
// POST: random returns a pseudo-random
//
number r in the range 0 <= r < 1
{ ...
} // random
Checking Preconditions
• Can throw exceptions
public double squareRoot (double x)
// PRE: x >= 0
// POST: ...
{ if (x < 0)
throw new IllegalArgumentException("x<0");
...
Assertions
• Similar to preconditions and postconditions
• Introduce the idea of checkpoints in the
program
– Describe the state of the program at certain
points
Example
• A program to play a card game
class PlayingCard
{ ... }
PlayingCard deck[] = new PlayingCard[52];
. . .
shuffleCards(deck);
// ASSERT: deck contains 52 cards in
//
random order
Assertions
• Some programming languages provide
mechanisms to check simple assertions
• Java does (since JDK 1.4)
– assert statement
– Two forms:
assert boolean_expression;
assert boolean_expression : expression;
Using Assertions in Java
. . .
skipSpaces();
ch = (char)System.in.read();
assert ch != ' ';
java.lang.AssertionError
at MyApp.main(MyApp.java:12)
Exception in thread "main"
Assertions in Java
• Assertion checking is disabled by default
– Allows checking to be done during
development
– When program is shipped to customer,
checking is disabled for efficiency
• Full details in Sun documentation
Using Assertions
• Some conditions are too difficult to express
as simple boolean expressions
– Use assertion comments
shuffleCards(deck);
// ASSERT: deck contains 52 cards in
//
random order
Assertions and Preconditions
and Postconditions
• Related concepts:
– Assertions: general checkpoints
– Pre- and postconditions: specific checkpoints
(at start and end of methods)
Assertions and Preconditions
• Assertions can be used to check preconditions
– better to use exceptions
public double squareRoot (double x)
// PRE: x >= 0
// POST: ...
{ assert x >= 0;
...
Benefits of Using Assertions,
Preconditions and Postconditions
• Forces the programmer to consider the state
of the program at key points
• Helps document the program
– Assumptions and “guarantees”
• May provide run-time checking