Follow the transformation
State the small task and expected result before coding.
Use the concepts from this module rather than introducing unnecessary new machinery.
Inspect intermediate values on the tiny example.
Functions & Reusable Code · Lesson 72
Mini Lab Reusable KPI Functions
This mini lab packages a KPI definition into a function so numerator, denominator and invalid-denominator handling are applied consistently wherever the metric is used.
Mini Lab Reusable KPI Functions
This mini lab packages a KPI definition into a function so numerator, denominator and invalid-denominator handling are applied consistently wherever the metric is used.
Learning goal: explain why Mini Lab Reusable KPI Functions behaves this way, apply it to a small example, and verify the result independently. Begin by being able to justify this first step: State the small task and expected result before coding.
Deeper walkthrough
Read Mini Lab Reusable KPI Functions as a mechanism, not a recipe
Treat this as a sequence of observable decisions rather than one opaque command. Stage 1: State the small task and expected result before coding. Stage 2: Use the concepts from this module rather than introducing unnecessary new machinery. Stage 3: Inspect intermediate values on the tiny example. Final checkpoint: Explain why the final result follows from the code.
Know what would convince you
- Trace a tiny input by hand and compare the runtime result.
- Inspect type, value/shape and any mutation/side effect explicitly.
Useful distinctionInput: Objects/values supplied to the operation.
Click a stage to inspect what happens, what changes, and what should be checked before moving on.
Stage 1
State the small task and expected…
State the small task and expected result before coding. For Mini Lab Reusable KPI Functions, identify the exact state before this stage, the operation or rule applied here, and the observable state afterwards so the mechanism remains inspectable.
State focus: identify exactly what changed at this stage and what observable evidence confirms that change.
Trace the mechanism step by step
- State the small task and expected result before coding.
- Use the concepts from this module rather than introducing unnecessary new machinery.
- Inspect intermediate values on the tiny example.
- Check at least one edge case.
- Explain why the final result follows from the code.
Mini Lab Reusable KPI Functions
# Step 1 — Define the reusable `rate` function; its indented body describes what happens for each call.
def rate(numerator, denominator):
# Step 2 — Evaluate this condition and execute the indented branch only when the condition is true.
if denominator <= 0:
# Step 3 — Raise an explicit exception to signal that the required condition or input contract was violated.
raise ValueError("denominator must be positive")
# Step 4 — Return the computed value to the caller so the result can be reused or tested.
return numerator / denominator
# Step 5 — Display the current value explicitly so the result/state can be inspected during execution.
print(rate(25, 100))Expected / illustrative result
The function returns 0.25 and rejects an invalid non-positive denominator.
Interpret the result.
For Mini Lab Reusable KPI Functions, trace the specific input through the mechanism above and independently verify one returned value, state change or side effect.
Place the concept correctly
InputObjects/values supplied to the operation.StateNames or mutable objects that may change during execution.OutputReturned value, side effect, file, plot or exception to inspect.When it is appropriate
Use Mini Lab Reusable KPI Functions when it answers a defined question in Functions & Reusable Code and its inputs/assumptions match the current data or program state.
When to stop or reconsider
Reconsider Mini Lab Reusable KPI Functions when the required information is unavailable, the operation would violate a validation/data boundary, or a simpler operation answers the question more transparently.
Failure modes to recognise
- Running the operation on the wrong object/type or in the wrong environment.
- Inferring correctness from “no exception” without checking the produced value/state.
- Hiding a boundary case instead of making its behaviour explicit.
How to check the result
- Trace a tiny input by hand and compare the runtime result.
- Inspect type, value/shape and any mutation/side effect explicitly.
- Run an edge or invalid case and confirm the exception/behaviour is deliberate.
Demonstrate understanding
Try this:
Construct a tiny example of Mini Lab Reusable KPI Functions. First state the small task and expected result before coding. Then use the concepts from this module rather than introducing unnecessary new machinery. Predict the result before execution and explain one boundary or failure case.
Use the smallest values that expose the language rule. Write the expected value and type first, then compare the actual state/output with that prediction.
Check reasoning, not memorisation
Which approach best demonstrates understanding of Mini Lab Reusable KPI Functions?
Remember the logic
Step 1State the small task and expected result before coding.Step 2Use the concepts from this module rather than introducing unnecessary new machinery.Step 3Inspect intermediate values on the tiny example.Step 4Check at least one edge case.What to remember
- This mini lab packages a KPI definition into a function so numerator, denominator and invalid-denominator handling are applied consistently wherever the metric is used.
- State the small task and expected result before coding.
- Running the operation on the wrong object/type or in the wrong environment.
- Trace a tiny input by hand and compare the runtime result.