WA Computer Science ATAR Year 11 — Modular Programming Hangman

The 62 key terms

1decomposition

Splitting a big problem into smaller sub-problems, such as input, process and output. Each part can be solved on its own, then the solutions are combined.

2structure diagram

A diagram with the whole problem in a top box, joined by lines to lower boxes for each sub-problem, in levels. It shows the parts of the problem, not the order of the steps.

3top-down design

Name the whole problem in the top box, then split it into sub-problems level by level until each box is one simple task. Use clear box names.

4team work and reuse

Different programmers write separate sub-problems at the same time, using their own skills, and finished parts such as a validation subroutine can be reused in other programs.

5single point of change

Code kept in one subroutine is edited once, so every CALL gets the update. Repeated copies must each be changed, and missing one gives inconsistent results.

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

7procedure vs function

A procedure carries out a task without returning a value, while a function returns a value to the code that called it, so the result can be stored or used.

8define

A keyword that starts a function definition, naming the function and listing the parameters it accepts

9addNumbers(a: INTEGER, b: INTEGER): INTEGER

A function header specifying the function's name, its typed parameters, and the data type of its return value

10addNumbers(3, 4)

Calling a function by writing its name followed by arguments in brackets, running its instructions and possibly producing a value

11return

A keyword that sends a value back from a function to where it was called, ending the function's execution at that point

13def main(): greet()

A function can call another function inside its body. Big problems get split into small helper functions that each do one job, like boxes in a decomposition.

14def main():

Defines a function called main that holds the main steps of your program. You call main() once at the end of the file, after the other functions are defined, to start the program.

16parameter

The name in a function definition that receives a value, like name in def greet(name). The value passed in the call, like greet('Ava'), is the argument.

21if is_even(n):

Calls a function that returns True or False and uses that result directly as the if condition. You do not need to write == True. It can also be combined with not, and, or.

22def total_of(scores):

A function header with a list parameter. Pass a list when you call it, like total_of([5, 8, 9]), and the function can loop over or read its items.

23copy = items[:]

A function can change a list you pass in, altering the original in place. Make a copy with [:] first if you need to keep the original list unchanged.

24side effect

A change a function makes outside itself, like printing, editing a global or changing a passed-in list. A pure function has no side effects and only returns a result from its inputs.

26local variable

A variable declared inside a subroutine. It keeps the subroutine self-contained, so changing it cannot accidentally alter other parts of the program, and the subroutine is easier to test alone.

27global

A keyword used inside a function so it can assign to a variable defined outside all functions, instead of creating a new local variable with the same name.

28GST_RATE = 0.1

A constant: a named value set once and never changed while the program runs. Written in UPPER_CASE by convention, it replaces magic numbers and is easy to update in one place.

29NameError

An error Python raises when code uses a variable or function name it does not know, often from a typo, wrong capitals, missing quotes or using a name before it is assigned.

32library

A collection of ready-made code you can reuse. The standard library comes with Python; third-party libraries are made by others and must be installed separately (e.g. with pip).

33import math

Loads Python's math module, giving you extras like math.sqrt(), math.pi, math.ceil() and math.floor() that basic operators don't have. Call them with the math. prefix.

34refactoring

Rewriting working code to make it clearer or simpler (e.g. renaming variables, moving repeated lines into a function) without changing what it does, then re-running tests.

35naming convention

An agreed pattern for naming variables, functions and controls so code is readable, consistent across a team and easier to maintain and debug.

36studentFirstName

Camel casing: join words with no spaces, start with a lower case letter, then capitalise the first letter of each later word, e.g. studentFirstName or calculateTotal.

37snake_case

A naming convention that writes every letter in lower case and joins words with underscores, e.g. student_first_name. Python uses it for variables and functions.

38Hungarian notation

A naming style where a variable name starts with a short lower-case prefix showing its data type, e.g. strName, intAge, fltPrice, blnPassed.

41internal documentation

Comments inside the code, like a header with purpose, author and date, and notes on each function, that help others (or you later) understand and safely change the program.

42# array used because size is fixed

A comment that explains what a variable, array, record or algorithm is for and why it was chosen, rather than just repeating what the code does.

43"""docstring"""

A triple-quoted string on the first line of a function or class body. It documents what the code does, its parameters and its return value. help() displays it.

44header comment

A comment at the top of a file that records the program's purpose, author, date and any changes made, so others can understand and maintain the code.

45pass

A Python statement that does nothing. It fills a stub's empty body, often beside a # TODO comment, so the program still runs while the real code is written later.

46readable code

Code that people can quickly understand, using clear names, consistent indentation and spacing, short functions with no repeated code, and helpful comments.

47maintainable code

Code organised so it can be fixed or extended later without breaking other parts, using small functions, classes that hide detail and constants instead of repeated values.

48normal, boundary and invalid data

A good test set uses normal data (typical values), boundary data (values at the edges of a range) and invalid data (values that should be rejected), so every path in an algorithm is checked.

49expected output

The correct result of a test case, worked out by hand from the specification before running the code. Never copy it from the program's own output, or the test proves nothing.

50unit testing

Testing one function or class on its own, with its own test table, before joining it to the rest of the program, so a failing test points to that module.

51test table

A table with one row per test case. Its columns are test number, purpose, input, expected result, actual result and pass or fail.

52Pass or Fail

Copy the actual result exactly as the program gave it, then mark Pass only if it matches the expected result, otherwise Fail. Never change the expected result to fit, and add a note for fails.

53test case

A chosen input paired with the output you expect. Run the program with it, compare the real output to the expected result in your test table, then record pass or fail.

54assert

Checks a condition is True, like assert add(2, 3) == 5. If the result is not what you expected, it raises an AssertionError, so test cases can run automatically.

55tests = [(5, 25), (0, 0)]

A list of (input, expected) tuples. Each tuple is one test case, so a loop can run many tests stored in one variable. Add a new tuple to add a new test.

56for value, expected in tests:

Loops over each (input, expected) tuple in tests, unpacking it into two variables. Then you call the function, compare actual to expected, and print PASS, or FAIL with both values.

57assert not is_valid(-5)

Tests that bad input is rejected: call the validator with an invalid value and assert it returns False. If an error is expected, use try/except; no error means the test fails.

58test first

Write test cases and expected results from the requirements before coding, so they check what the program should do, not what your code does. Rerun them as it grows.

59test coverage

Testing so that every if/elif/else branch runs at least once and every loop is tried running zero times, once and many times. Any code never run is untested.

60runtime error

An error that stops a program while it runs, shown as a named error like NameError, ValueError or ZeroDivisionError. Read the message to find the problem.

61Traceback (most recent call last):

The start of Python's error report. It names the error type (like NameError) and the line number where it happened, so you know where to start looking for the bug.

62IndexError

A runtime error raised when code uses an index that is not in the list, such as items[5] in a 5-item list. The last valid index is len(items) - 1.

63logic error

A mistake that lets a program run with no error message but give the wrong result, caused by a wrong condition, operator (> or >=), range() off by one, or steps in the wrong order.

64print(variable)

Debugging tool: print a variable at key points, then compare each value with your trace table of what it should be. The first mismatch shows where the bug is.

65breakpoint

A marker set on a line of code (click beside the line number) that pauses the program there in debug mode, so you can inspect variables and step through the code.

66step through

Run paused code one line at a time using step over, step into or step out, while the watch panel shows each variable change, to find where a value goes wrong.

67regression testing

After fixing a bug, rerun the failed test and all earlier tests, because a fix can break code that used to pass.

68modify code

Read and trace the code first to see what it does, then change one small part at a time and re-run your test cases to check the effect of that change.

69IPO chart

A table with Input, Process and Output columns that lists what the user enters, the calculations and decisions the code makes, and the results or messages it displays.

70IPO to pseudocode

Turn each IPO input into an INPUT statement, each process into assignments or IF selection, and each output into a PRINT statement, in that order.

71data dictionary

A table listing each data element with its name, data type, size or format, description and validation rule, so everyone uses the data the same way when coding and testing.

72internal vs external documentation

Internal documentation is inside the code (comments, docstrings). External is separate, like a user guide or technical document covering each module's purpose, inputs and outputs.

73test report

A summary of how many tests passed and failed, what was fixed and retested, and a conclusion on whether the program is validated, backed by the results and any limitations.