Subroutines make programs easier to test and read

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. A program is split into small named subroutines. Why does this make errors easier to find?

A The computer automatically fixes errors inside subroutines

B Each subroutine can be tested on its own, so the faulty one is quickly located

2. Which subroutine name best shows its purpose?

A CalculateAverage

B DoStuff

3. How could you test a function called IsPrime on its own?

A Call it with different test inputs and check each returned value

B Run the whole program and hope IsPrime is used somewhere

4. Which main program is easier to read?

A One block of 200 lines with no subroutines

B CALL GetNames() then CALL SortNames() then CALL ShowNames()

5. True or false: Splitting a program into subroutines lets several programmers work on different parts at the same time.

A True

B False

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1CALL ShowMenu()		AOne large subroutine with a vague name does many jobs, so it is hard to read and an error is hard to locate. Split it into small subroutines with descriptive names.
2OUTPUT CalcTotal(5, 3)		BFUNCTION IsPassMark(Score : INTEGER) RETURNS BOOLEAN
3A descriptive name shows the purpose of a subroutine, so a reader understands it without reading its code		CNames like P1 and P2 do not show purpose, so other programmers working on different subroutines cannot tell what each one does. Use descriptive names such as ReadMarks.
4A short main program can read like a list of steps because each step is a named subroutine		DTests one subroutine alone by giving it known inputs and checking the output is what you expect
5PROCEDURE DoStuff() // 80 lines: input, maths and output ENDPROCEDURE		ECALL GetScores() CALL ShowResults()
6PROCEDURE P1() PROCEDURE P2()		FA main program line that reads like a step in a list and tells the reader what happens without showing the detail

Definitions

modular program

Fill in the Blanks

Complete each line of code by filling in the missing parts.

____ ShowMenu() CALL GetChoice() CALL ShowResult()

FUNCTION IsEven(N : INTEGER) RETURNS _______ RETURN N MOD 2 = 0 ENDFUNCTION

// Test: Square(5) should give 25 OUTPUT Square(_)

PROCEDURE DisplayScore(Score : INTEGER) OUTPUT "Score: ", Score ____________

FUNCTION IsPass(M : INTEGER) RETURNS BOOLEAN ______ M >= 50 ENDFUNCTION

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A FUNCTION Half(N) RETURNS REAL

B RETURN N * 2

C ENDFUNCTION

D OUTPUT Half(10)

Question 2

A CALL ReadMarks()

B FindAverage()

C CALL ShowResult()

Question 3

A FUNCTION Tax(P) RETURNS REAL

B OUTPUT P * 0.2

C ENDFUNCTION

Question 4

A PROCEDURE ShowTotal(T)

B OUTPUT "Total: ", T

C ENDPROCEDURE

D CALL ShowTotal()

Question 5

A FUNCTION Area(W) RETURN REAL

B RETURN W * W

C ENDFUNCTION

Answer Key

Subroutines make programs easier to test and read

Section A: Quick Questions

B — Each subroutine can be tested on its own, so the faulty one is quickly located

A — CalculateAverage

A — Call it with different test inputs and check each returned value

B — CALL GetNames() then CALL SortNames() then CALL ShowNames()

A — True

Section B: Match the Pairs

CALL ShowMenu() → A main program line that reads like a step in a list and tells the reader what happens without showing the detail

OUTPUT CalcTotal(5, 3) → Tests one subroutine alone by giving it known inputs and checking the output is what you expect

A descriptive name shows the purpose of a subroutine, so a reader understands it without reading its code → FUNCTION IsPassMark(Score : INTEGER) RETURNS BOOLEAN

A short main program can read like a list of steps because each step is a named subroutine → CALL GetScores() CALL ShowResults()

PROCEDURE DoStuff() // 80 lines: input, maths and output ENDPROCEDURE → One large subroutine with a vague name does many jobs, so it is hard to read and an error is hard to locate. Split it into small subroutines with descriptive names.

PROCEDURE P1() PROCEDURE P2() → Names like P1 and P2 do not show purpose, so other programmers working on different subroutines cannot tell what each one does. Use descriptive names such as ReadMarks.

Section C: Definitions

modular program — A program split into small named subroutines. Each one can be tested alone and read quickly, so errors are easier to find and the whole program is easier to understand.

Section D: Fill in the Blanks

CALL ShowMenu()
CALL GetChoice()
CALL ShowResult()

FUNCTION IsEven(N : INTEGER) RETURNS BOOLEAN
  RETURN N MOD 2 = 0
ENDFUNCTION

// Test: Square(5) should give 25
OUTPUT Square(5)

PROCEDURE DisplayScore(Score : INTEGER)
  OUTPUT "Score: ", Score
ENDPROCEDURE

FUNCTION IsPass(M : INTEGER) RETURNS BOOLEAN
  RETURN M >= 50
ENDFUNCTION

Section E: Spot the Error

B — Testing Half on its own with the input 10 should give 5, but N * 2 gives 20. Because the function is small and separate, the fault is easy to find. The line should be RETURN N / 2.

B — The main program is a list of steps, and each step must start with CALL to run a procedure. Line 2 should be CALL FindAverage().

B — A function must RETURN its value so that it can be tested alone and used by other code. OUTPUT only displays the number. The line should be RETURN P * 0.2.

D — To test the procedure alone you must give it its own input. ShowTotal has one parameter, so the call needs a value, for example CALL ShowTotal(50).

A — The header of a function must use the keyword RETURNS before the data type. The line should be FUNCTION Area(W) RETURNS REAL.