Identifying Tasks: To determine necessary sub-procedures, analyze the problem description for distinct actions or verbs (e.g., 'calculate', 'validate', 'display').
Defining Interfaces: For each sub-procedure, you must define the parameters (data passed in) and the return type (data passed back, if any).
Unit Testing: Each sub-procedure should be tested independently of the main program to ensure it handles all edge cases and produces the correct output for given inputs.
Refinement: Continue decomposing tasks until each sub-procedure performs exactly one logical function; if a procedure is doing too much, it should be split further.
| Feature | Procedure | Function |
|---|---|---|
| Return Value | Does not return a value to the calling code. | Returns a single value to the calling code. |
| Usage | Used to perform an action or change state. | Used to perform a calculation and provide a result. |
| Call Style | Called as a standalone statement. | Often used within an expression or assignment. |
Identifying Sub-procedures: When given a scenario, look for high-level features that provide user options or handle complex logic, such as 'User Login', 'Score Calculation', or 'Data Validation'.
Avoid Triviality: In exams, simple actions like 'moving a cursor' are often considered too basic; focus on procedures that involve logic, data transformation, or state changes.
Check Parameters: Always verify that the data being passed into a sub-procedure matches the expected data types (e.g., passing an Integer when a String is expected is a common logic error).
Hierarchy Accuracy: Ensure your hierarchy charts show a clear parent-child relationship where the parent 'calls' or 'contains' the child tasks.
Over-Decomposition: Breaking a problem into too many tiny sub-procedures can make the program flow difficult to follow and increase the overhead of passing data.
Global Variable Reliance: Relying on global variables instead of passing parameters makes sub-procedures less portable and harder to debug, as any part of the program could change the data.
Confusing Procedures and Functions: Using a procedure when a return value is needed (or vice versa) leads to logic errors where data is 'lost' or the program structure becomes awkward.
