Skip to content
Gallery
Software Design and Development
Software Design and Development
Week 4
Week 5
Week 6
Week 7
Week 8
More
Share
Explore
Week 7

Learning Preparation

Techniques for Well Written Code

The main line of the code is clear and uncluttered, with minimal control structures.
Each subroutine focuses on one logical task.
Appropriate use of control structures and data structures.
Correct use of data types to avoid errors.
Comments and stubs are used to aid program maintenance.

Types of Errors

info

There are 3 main types of errors in code: Syntax, Logic, and Runtime

Syntax Error

Occurs when code doesn’t match syntax os language
Detected on compilation, syntax errors will result in the program being unable to compile
Examples include missing brackets, mispelt/missing keywords, etc.
func syntaxErrorExample {
print("error")
}
// This code would result in a syntax error due to the lack of () at the end of the function name.

Logic Error

Where the algorithm of the code does not produce the required action
Errors detected during testing, when using test data to check the the program works as it should
Code with a logic error will run but not produce the required output
func printUsername() {
var username = "hlewandowski"
print("username")
}
// Result: username
// This code means to print the string in var username, but instead prints the string "username".

// Replacing print("username") with print(username) would fix this issue.

Runtime Error

Occurs while the program is running
Causes the program to terminate or stop, and could be the result of a logic error
Examples include division by zero, overflow, or memory location errors

Error Detection and Correction

info

A number of tools and techniques can be used to find logic and runtime errors.

Flags
Stubs and Drivers
Debugging output statements
Peer checking
Desk checking
Structured walk through
Comparing actual and expected output

Stubs

Stubs are used to check
The flow or connection between the modules (sub programs) are working
If a subroutine is causing an error by replacing it with a sub (to check if the error disappears, if it does then the error would be in the subroutine)
A section of code, before all sub programs required by that code are finished
// STUB EXAMPLE

REM the following program works out the surface area of a cylinder
DECLARE SUB circ (radius)
DIM SHARED area AS SINGLE
DIM SHARED perimeter AS SINGLE
DIM radius AS SINGLE
DO
INPUT "Please enter the radius of the cylinder"; radius
INPUT "Please enter the length of the cylinder"; length
CALL circ(radius)
surfarea = 2 * area + perimeter * length
PRINT "The surface area is "; surfarea
INPUT "Do you want to do again? (Y/N)"; again$
LOOP UNTIL UCASE$(again$) = "N"
END

SUB circ (radius)
area = 30
perimeter = 10
END SUB

// In the first example above, the sub program “circ” has not yet been complete, so some (arbitrary) values are return from the sub program, so that the rest of the program can be tested (e.g. the surface area formula for a cylinder). “circ" is therefore acting as a stub.

Drivers

A driver is a portion of code that mimics the function of the main line (main program). They are used when the main program is not yet complete and the developers wish to test modules (subroutines). The driver will pass data to the modules and output the returned values. In a sense, a driver is the reverse of a stub.
// DRIVER EXAMPLE
//this is the “add” module that will be tested by the driver
function add(a, b) {
return a + b;
}

//this is the “multiply” module that will be tested by the driver
function multiply(a, b) {
return a * b;
}

//this is the driver that is testing the two modules
function driver() {
const a = 3;
const b = 4;
const sum = add(a, b);
const product = multiply(a, b);
console.log(`sum: ${sum}, product: ${product}`);
}

//calling the driver
driver();

Flags

Flags are used to check that a section of code has been processed or executed. They can be used as part of a solution or as an error detection process. They are normally Boolean variables that change to true (1) if the line of code is executed, e.g. $found = true;
// FLAG EXAMPLE
struct BubbleSortView: View {
@State var sorted = false
var body: some View {
NavigationStack {
VStack {
if sorted == false {
Button("Sort")
else {
Button("Unsort")
{
{
{
{

// This example uses the var sorted to change the button in the UI depending on whether the array has been sorted or not.

Debugging Output Statements

Debugging Output Statements are additional print/output statements in the code that help in telling what part of the code has executed or for working out what is happening to the program, especially what values the variables are holding. They can also be used to check if a section of code has been executed or to interrogate the values variables held at a particular point in the program i.e. print the value of a variable echo “$count”;
// The cylinder program used previously can have output statements placed in the code to let the user know what the values of area and perimeter before surfarea is calculated and to show if the subprogram was executed.

REM the following program works out the surface area of a cylinder
DECLARE SUB circ (radius)
DIM SHARED area AS SINGLE
DIM SHARED perimeter AS SINGLE
DIM radius AS SINGLE
DO
INPUT "Please enter the radius of the cylinder"; radius
INPUT "Please enter the length of the cylinder"; length
CALL circ(radius)
PRINT "The area is "; area
PRINT "The perimeter is "; perimeter
surfarea = 2 * area + perimeter * length
PRINT "The surface area is "; surfarea
INPUT "Do you want to do again? (Y/N)"; again$
LOOP UNTIL UCASE$(again$) = "N"
END

SUB circ (radius)
area = 3.14 * radius * radius
perimeter = 2 * radius * 3.14
PRINT “subprogram executed”
END SUB

Peer Checking

Constant and ongoing process
Involves developers reviewing code and providing feedback
Often occurs informally through flow of comments and ideas

Desk Checking

Using a tabular method to systematically monitor the changes in variables

Structured Walkthrough

Formal peer checking
Consists of a presentation in front of shareholders or people involved with the project

Comparing Actual and Expected Values

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.