A program repeats the same discount calculation in five places. After the rules change, a pupil edits four copies but misses the fifth. Another script prints an answer instead of returning it, so the next calculation receives no useful value. Functions solve these problems by turning a defined operation into a named, testable part of a program, with clear inputs and outputs.
This independent Ministry of Education V3.0 reference develops the 2027 Singapore G3 Computing K349 Python curriculum through user-defined functions, parameters and arguments, return values, local and global variable use, modular problem solving, incremental testing, trace tables, normal/boundary/error cases and input validation. It includes 26 original worked Python scenarios, a twelve-stage Define–Call–Return–Verify protocol, a small fictional learning-centre program and eduKate Depth–Load–Transfer diagnostics.
All students, identifiers and data in examples are fictional. This resource is not an official MOE/SEAB paper or a deployable administrative application. Code is for learning; actual systems handling grades, accounts or personal data require additional security, privacy, error handling and authorised review.
1. A Function Is a Reusable Piece of Behaviour
A function is a named block of instructions which may receive arguments through parameters and may send back a result through a return statement. It supports decomposition: one large task can be divided into smaller problems which are easier to test. In Python, defining a function does not necessarily run it immediately; an appropriate call executes its body.
2. Exact 2027 G3 Computing K349 Outcomes
The official K349 2027 G3 Computing syllabus, Module 2.3 Python Code, explicitly requires pupils to write and call user-defined functions that may accept parameters and/or provide return values (2.3.13), and to distinguish local from global variables (2.3.14). Module 2.4 covers trace tables, debugging, incremental testing, input validation and normal, error and boundary cases. Module 2.5 covers modular and incremental solutions. The official Python Quick Reference Guide shows def function_name(parameters):, an indented body, return and a function call. This article stays near those outcomes rather than presenting complex decorators, web APIs or object-oriented architectures as compulsory.
3. Parameters and Arguments Have Different Jobs
A parameter is the name used in a function definition, such as quantity in def double(quantity):. An argument is the actual value supplied at the call site, such as 4 in double(4). Parameters are placeholders until the function is called. Confusing the two can make a student think that writing a function definition automatically sets a parameter to a fixed value.
4. Return and Print Are Not Interchangeable
print() displays a value; return supplies a value to the code that called the function. A function that prints 12 but does not explicitly return a result normally evaluates to None as a returned value. If the next line needs to multiply the calculated answer, it must receive a suitable returned number, not rely on text shown on screen.
5. Local Names Are Defined in a Scope
A local variable created inside a function ordinarily belongs to that function’s local scope. A global variable is defined at module level, outside functions, and can be read in appropriate situations. Reusing the same name locally does not automatically change a module-level variable. Students should trace exactly which name is being read rather than assume all variables with identical spelling are one storage location.
6. Modularity Makes Errors Easier to Locate
If a program has separate functions for checking input, calculating a total and formatting a result, it can test each function before combining them. This does not prove the functions are automatically correct, but it narrows where a fault might be. A well-defined function has one understandable purpose and a clear expectation for valid and invalid inputs.
7. Validation Guards the Entrance
K349 Module 2.4 identifies presence, length, range, format, existence and check-digit validation methods. Validation checks whether supplied data meet stated acceptance rules; it does not prove that an accepted fact is true. For an interactive program, invalid input may prompt the user to enter it again. For a non-interactive processing situation, exiting the program or appropriately rejecting the data may be required.
8. Eight Rooms of Function Reasoning
Room one defines the input. Room two names the output. Room three chooses parameters. Room four constructs a properly indented body. Room five selects return or print according to caller needs. Room six traces local and global names. Room seven tests normal, error and boundary conditions. Room eight transfers the design to an unfamiliar problem independently.
9. Twelve-Stage Define–Call–Return–Verify Protocol
Stage 1 — State the function’s purpose
Write one sentence describing the transformation, such as ‘convert minutes into seconds’. If the purpose is unclear, the inputs and tests will also be unclear.
Stage 2 — Identify inputs and their types
Decide whether the parameter should be an integer, float, string or list. A string of digits is not automatically a number suitable for arithmetic.
Stage 3 — Define valid input conditions
A number of attendees may need to be a nonnegative integer; a denominator cannot be zero. State acceptable boundaries before assuming all supplied values are safe.
Stage 4 — Select meaningful parameter names
Use minutes rather than an unexplained x when teaching a time conversion. The function name and parameters should reveal the intended relationship.
Stage 5 — Write valid indentation
In Python, statements inside the function belong to an indented block. A misplaced line may execute outside the intended body or cause a syntax/indentation error.
Stage 6 — Compute the required result
Keep the arithmetic and logical rules separate from output presentation where possible. The body should implement the input–output contract.
Stage 7 — Return the value the caller needs
Use return result where subsequent code should reuse it. Use print separately for display if the task requires visible output.
Stage 8 — Call with correct arguments
A function expecting two required parameters normally needs two suitable arguments. Check order and meaning rather than treating every integer as interchangeable.
Stage 9 — Trace local variables
Track parameter bindings and temporary values inside the call. Check whether a name with the same spelling exists outside in a different scope.
Stage 10 — Build normal and boundary tests
Try typical valid inputs, minimum or maximum accepted inputs and cases exactly on a decision threshold. A function correct for 5 may fail for 0 or 10.
Stage 11 — Test errors and repair incrementally
Identify syntax, run-time or logic errors. Use small manual trace tables or temporary print statements to locate a wrong value, then retest.
Stage 12 — Reuse in a different task
Call the same suitable function with new arguments or combine it with another function. Independent transfer means the learner can predict outputs before running the code.
10. Original Fictional Program: Library Loan Tally
Imagine a fictional school library calculating the number of minutes for which a borrowed item is overdue. One function returns the nonnegative difference between actual return time and agreed due time. Another determines whether a reminder is needed. Dates, permissions and real library policies are omitted from this controlled model. The purpose is to compare parameters, returned values and independent tests.
def overdue_minutes(actual, due):
difference = actual - due
if difference > 0:
return difference
return 0
def needs_reminder(overdue):
return overdue > 0
late = overdue_minutes(108, 100)
print(late)
print(needs_reminder(late))The code prints 8 and then True. The first call binds actual=108 and due=100; it returns 8. The second call receives 8 and returns the Boolean result of 8>0. If actual were 95 and due 100, the first function would return 0. Real-world time-of-day and date calculations require further assumptions, so do not turn this simplified example into a production library system.
11. Twenty-Six Worked Python Function Scenarios
12. Worked Example A — Defining does not call
After def square(n): return n*n is correctly expressed with an indented body, merely defining it produces no automatic printed answer. The call square(3) computes 9 as its return value.
13. Worked Example B — Single-parameter call
def double(n): return 2*n, when called with 7, returns 14. The symbol n is the parameter; 7 is the supplied argument.
14. Worked Example C — Two parameters
def area(w,h): return w*h called with (4,6) returns 24. The arguments correspond to width and height in the order used by this function.
15. Worked Example D — Argument order matters
def difference(a,b): return a-b called with (9,4) returns 5, while (4,9) returns −5. Two numbers cannot always be interchanged without changing meaning.
16. Worked Example E — Return versus print
def show(n): print(n*2) displays the doubled number but ordinarily returns None. By contrast def twice(n): return n*2 returns a value suitable for later arithmetic.
17. Worked Example F — A local temporary value
In a function def fee(q): amount=q*3; return amount written with proper lines, amount is a local temporary. A caller cannot assume that a module-level variable called amount has been changed.
18. Worked Example G — A global value is read
Given module-level rate=2, the function def cost(n): return n*rate can read rate. Calling cost(5) returns 10 as long as rate remains 2.
19. Worked Example H — Local shadowing
Given x=10 at module level, def f(): x=2; return x returns 2 when called, while the external x ordinarily stays 10. Trace each scope separately.
20. Worked Example I — A Boolean result
def adult(age): return age>=18 returns False for age 17 and True for 18. This is a programmed condition, not a complete legal eligibility test in real life.
21. Worked Example J — A zero boundary
def nonnegative(n): return n>=0 returns True for 0. Changing the operator to greater-than alone incorrectly excludes the boundary.
22. Worked Example K — Choosing one of two results
A function def bigger(a,b): with if a>b: return a and return b returns the larger value for comparable numbers. When equal, it returns b, which has the same numeric value.
23. Worked Example L — Missing return on one path
def positive(n): containing only if n>0: return n has no explicit return for n=0 or a negative number; that call returns None. Consider every control-flow path.
24. Worked Example M — String argument
def greet(name): return 'Hello '+name called with ‘Kai’ returns ‘Hello Kai’. Passing an integer without conversion can cause a type error because the operation expects strings.
25. Worked Example N — Length check
def valid_code(code): return len(code)==4 checks that the argument has length four, not that its characters are all digits. Validation conditions should match the actual input requirement.
26. Worked Example O — Range check
def valid_score(s): return 0<=s<=100 accepts 0 and 100 while rejecting −1 and 101. It assumes s supports numerical comparison; unexpected text input needs separate handling.
27. Worked Example P — Format check
def digits(text): return text.isdigit() can check whether a string contains digit characters, but it does not guarantee that the sequence represents a real customer account or an accurate input fact.
28. Worked Example Q — A list total without sum
A function loops through [2,3,5], starts total=0 and adds each value, returning 10. The accumulator must be initialised before the loop and returned afterward.
29. Worked Example R — A local counter
A function sets count=0, loops over [1,0,2] and increments for values greater than zero. It returns 2. Count must not be reinitialised inside the loop.
30. Worked Example S — Extract a small piece
def first(text): return text[0] works for nonempty strings. For an empty string it raises an indexing error, demonstrating why a presence/length check may be needed.
31. Worked Example T — Zero division
def average(total,n): return total/n cannot safely process n=0. A valid-input requirement that n be positive, or an appropriate error-handling approach, should be designed explicitly.
32. Worked Example U — Trace a nested call
double(double(3)) first evaluates double(3)=6, then double(6)=12. Trace the inside call’s return before passing it to the outside call.
33. Worked Example V — Function composition
If add_one(4) returns 5 and triple(5) returns 15, calling triple(add_one(4)) returns 15. This demonstrates reusable building blocks, not the need to copy code twice.
34. Worked Example W — Normal test
A ticket-pricing function defined for 1 to 10 tickets is tested with 5. That is a normal valid case, useful but insufficient to establish boundary behaviour.
35. Worked Example X — Boundary test
For the same 1–10 input requirement, test 1 and 10. Those values check whether inclusive comparisons were correctly used. Also test 0 and 11 as invalid cases.
36. Worked Example Y — A syntax or runtime fault
Misindentation after def can produce a syntax-related failure, while attempting division by zero at runtime raises an exception. Identify the type before changing program logic.
37. Worked Example Z — Incremental testing
A program first validates a quantity, then computes a fee, then formats output. Test each function using known sample cases before combining them. When the final output is wrong, inspect the earliest function where expectations diverge.
38. Function Calls Create Temporary Bindings
When double(7) is called, its parameter n receives 7 for that call. A later call with 3 binds a fresh value for that invocation. The function definition did not permanently set n to the previous argument. This is essential for understanding why one function can serve different users and rows of data.
39. A Return Statement Ends That Execution Path
In an ordinary Python function, executing return immediately sends the specified value to the caller and leaves the function. Any statement after the executed return in the same path is not run. Students should trace whether a conditional branch returns early, as that can change which calculations occur.
40. Every Return Path Needs Consideration
A function that returns a fee when quantity is positive but has no return for zero may accidentally produce None. One solution is to define an explicit valid-input requirement and reject invalid data, or return a sensible value where the specification demands it. The correct policy must come from the problem, not from arbitrary habit.
41. Local Versus Global Is About Where Names Live
A module-level variable may be read from a function, but a name assigned inside normally becomes local to that function unless a specific language mechanism changes the binding. Avoid casually modifying global state merely to pass a calculated number. A returned result usually makes the dependency clearer in a school exercise.
42. Functions Enable Modular Testing
If a fictional system uses check_quantity(), calculate_fee() and describe_result(), a wrong result can be investigated in stages. If check_quantity fails, changing the fee formula is unlikely to repair it. Isolate the smallest part that does not meet its defined contract, then retest the integrated result.
43. A Test Case Must State Its Expected Result
Writing ‘test with 5’ is incomplete. A test needs an input, an expected output, the reason that case was selected and an observed result if the program is actually run. This distinguishes genuine verification from simply pressing Run and seeing that the screen contains a number.
44. Boundary Conditions Reveal Hidden Comparisons
Suppose valid marks range from 0 through 100 inclusive. Testing 50 checks a normal value, while 0 and 100 verify the endpoints. Inputs −1 and 101 are invalid cases. A function using 0<s<100 will pass normal tests yet reject both allowed boundary values.
45. Input Validation Is Not Fact Verification
A four-digit identifier may pass a format and length check while still belonging to nobody in the fictional system. An existence check against authorised records is a separate validation method. Even that does not establish that every historical detail in the record is accurate.
46. Interactive and Non-Interactive Errors Have Different Routes
When an interactive program asks a user for a quantity, invalid input can lead to another prompt under the given requirement. A batch-processing job with no user present cannot always ask again and may instead stop or report the invalid record. This distinction is named in K349’s input validation outcomes.
47. Debugging Begins at the First Unexpected Value
A final total of 96 rather than expected 60 might come from input reading, a loop adding twice or a wrong parameter. Inspect a trace table from the start and find the earliest divergence. Fix that cause and rerun the earlier passing cases; do not change the final printed number just to make one example look correct.
48. A Modular Design Should Not Hide Side Effects
A function that quietly changes a global attendance list can make other code depend on when it is called. For beginners, returning a new result or clearly describing any intentional changes simplifies reasoning. Modularity means predictable behaviour, not merely putting long code inside a def block.
49. Functions and the Python Quick Reference Guide
The K349 Quick Reference Guide shows the ordinary function definition with parameters and a return, alongside Python built-in functions and standard constructs. Use those supported operations to practise for the school syllabus. Sophisticated decorators, async web servers or database frameworks can be useful professionally but are not necessary to master the examinable function concept.
50. A Three-Pupil Function Workshop
Pupil A writes input conditions and expected outputs; pupil B defines and calls a function with parameters; pupil C traces scope and creates normal/boundary/error tests. Rotate roles with changed numbers and purposes. Each pupil then completes a new function independently, making a passed group example evidence of learning only after solo transfer.
51. eduKate Depth–Load–Transfer Diagnostic
Depth: can the pupil explain why print is not return and what a parameter means? Load: can they trace local/global names, function calls and multiple return paths in one task? Transfer: can they create and test an unfamiliar reusable function without borrowing the old code structure? The immutable Clementi small-group model informs this diagnose–repair–practice–independent method.
52. Parent and Tutor Questions
Ask ‘What must go into this function?’, ‘What is returned?’, ‘Where does this variable exist?’, ‘What happens at zero?’, ‘Does every branch return something?’, and ‘Can you predict the output without running the program?’ These questions test computational reasoning rather than memory of Python punctuation.
53. The Function Misconception Ledger
Mistake: defining a function runs it. Repair: distinguish def and call. Mistake: print passes a value back. Repair: trace a returned value. Mistake: local x always changes global x. Repair: track scopes. Mistake: one normal test proves correctness. Repair: add boundary and error cases. Mistake: a valid formatted string is guaranteed true. Repair: distinguish format checking from verification.
54. Frequently Asked Questions
What is a function parameter?
A placeholder name in the function definition for a value provided during a call.
What is an argument?
The actual value or expression supplied when a function is called.
Does defining a function immediately run it?
Not ordinarily. Its body executes when called.
What is the difference between return and print?
Return supplies a result to the caller, whereas print displays information.
What happens with no explicit return?
A Python function normally returns None.
What is a local variable?
A name bound within a function’s local scope, distinct from an unrelated module-level name.
Can a function read a global variable?
Yes, in appropriate circumstances. This is separate from assigning a new local variable of the same name.
What is a normal test case?
An ordinary valid input expected to work under the stated specification.
What is a boundary case?
An input at or immediately around a permitted limit, such as 0 and 100 for a score range.
Is validation proof that entered information is correct?
No. It checks stated acceptance rules but may not establish truth.
55. Independent Depth and Transfer Practice
Practice 1 — Define a conversion function
Write a function minutes_to_seconds(minutes) that returns minutes*60. Predict the returned values for 0, 1 and 7.
Practice 2 — Compare display and return
Define show_total(a,b) with print, and add(a,b) with return. Explain why only the second can be used directly in a later multiplication.
Practice 3 — Trace scope
Set rate=5 globally and define a function with local rate=2 returning rate*3. Predict the function result and the unchanged global rate.
Practice 4 — Find a missing branch
A function returns n when n>0 but says nothing otherwise. Explain what a call with 0 returns and repair according to a stated specification.
Practice 5 — Design a score validator
Accept numeric scores from 0 through 100 inclusive. Supply normal 50, boundaries 0 and 100, errors −1 and 101, and expected Booleans.
Practice 6 — Detect an index risk
A function accesses text[0]. Identify the invalid empty-string case and propose a presence check before indexing.
Practice 7 — Decompose a new problem
For a fictional stock order, define check_quantity and cost functions separately, identifying inputs, outputs and the point of integration.
Practice 8 — Independent transfer
Given a new need to classify a temperature, design a function, test threshold values and explain its limits without copying a previous library-loan example.
56. Closing Principle
A trustworthy function has a clear purpose, appropriate parameters, predictable return behaviour and tests that cover more than an ordinary case. Trace local names, validate inputs and isolate failures. Students demonstrate mastery when they can write and check a function for a new problem without the teacher supplying the code.
Related eduKateSG References and Official Sources
Extend Reference 310 — Python Strings, Lists and Files, Reference 203 — Computational Thinking, the MOE V3.0 Reference Library, and the immutable Clementi tutorial standard. Official curriculum: SEAB 2027 G3 Computing K349 Module 2.3–2.5 and Python Quick Reference Guide.
MOE V3.0 Reference Sequence Navigation
Previous: Reference 324 · MOE V3.0 reference library.